I have been using ADO.net since 2002/2003 and most of the application I have developed so far use ADO.net (I do use business objects in my application but underlying data access is through ADO.net)
Question: What is/will be next paradigm of data access technology assuming you are using .net framework and SQL Server?
I am hearing LINQ and Entity Framework but not sure about LINQ or at least its future?
Any advice along with a recommended book will be greatly appreciated.
Object relational mapping is perhaps the next paradigm for data access technology after ADO.NET, although you could say that its already pretty well established. Although Entity Framework is still fairly new NHibernate has been around for several years, and its Java predecessor since 2001.
If you are looking for a good book about NHibernate and object relational mapping in general then NHibernate in Action is good. Its very readable and the first chapter, which is available as a free sample, covers the rationale behind ORM as well as comparisons between NHibernate and other technologies like LINQ.
LINQ is here to stay, what I think you are referring to is LINQ to SQL which while not being very actively developed by Microsoft, is still alive however Microsoft are making it fairly clear that EF is the future.
Related
I am working on a new project which is to use Asp.net MVC 5 and Cassandra.
I am very OK working with entity framework.
Is there a way of connecting entity framework to a Cassandra database?
If not, can anyone help me with the necessary structures to have my MVC 5 application work with a Cassandra database?
More especially is the fact that i want to work with the MVC 5 identity.
I'll really appreciate any help.
All the old versions of EF, up to version 6.x, don't support NoSQL databases like Cassandra.
EF7 is still under development, but it's being designed to be flexible enough to support NoSQL databases. As of today, (Nov 2015) there isn't still any support for a NoSQL database in the current EF7 beta8. But we can expect to see it in the future.
For example you can see it mentioned in this article of MSDN magazine: Looking ahed to Entity Framework 7:
Beyond Relational
When Entity Framework was first introduced, Microsoft had a vision of it being used for a variety of data stores, though the first pass focused on relational databases. Non-relational databases existed at that time, but were not widely used, unlike the NoSQL databases—especially document databases—that are so popular today.
While EF is an Object Relational Mapper (ORM), developers who use it want to be able to use the same constructs to interact with non-relational databases. EF7 will provide a high level of support for this, but keep in mind what high level really means. There are vast differences between relational databases and non-relational databases and EF will not make any attempt to mask those differences. But for basic querying and updates, you’ll be able to use the patterns with which you’re already familiar.
I'm creating an article related to ado.net. I want to verify if this is true or not because some people said that using ado.net in accessing database is obsolete now. And what's the difference between ado.net, entity framework, ORM, O/R, linq? Could someone enlighten me? thank you very much!
Both LINQ to Entities and Entity Framework use ADO.NET internally, so I wouldn't say it's obsolete.
There are certain cases when using ADO.NET is recommended more then L2SQL and EF, especially when performance really matters and you are able to sacrifice the ease of writing code in exchange to full control over what is send to database and when.
Entity Framework & O.R.M. using ADO.NET on back end. These framework are more optimized and efficient than the simple ADO.NET. While LINQ To SQL are more faster than ADO.NET because it doesn't use the functionalities of ADO.NET
I heard that companies that use Java technologies, they used to build their own custom Framework that wraps Hibernate. However, is it really feasible for their .Net peers to do the same thing with NHibernate or Entity Framework?
This is almost always a horrible idea - I think Ayende sums it up best in this article. In general, you should consider NHibernate itself to be the "wrapper" around your data access - attempting to build an abstraction layer on top of it is probably going to be a losing proposition.
Actually, you should check out some of the articles on .NET Junkie's weblog. He wrote several great posts on how to deal with repositories, queries, commands and so on. We've been using these in a very large enterprise system where we switch between an in-memory dictionary, an in-memory SQLite database and a production environment using SQL Server or Oracle. Obviously, we use NHibernate for this.
I use the repository pattern and a separate project/dll to abstract away the data framework nhibernate / entity framework. this is a good starting point http://codebetter.com/petervanooijen/2008/04/04/wrapping-up-nhibernate-in-repositories/
I couldn't found a clear answer on that:
Is the ADO.NET Entity Framework a full featured persistence framework like Hibernate for Java?
Is there a any (other) persistence framework in .net? I only found open source frameworks like nHibernate but no clear answer if there is something build-in in .net. What's the best practice to get persistence in .net?
when you talk about persistence layer, usually that is databases or file systems, when you talk about Entity Framework it is called ORMs, and yes, I think in the .Net environment NHibernate and Entity Framework should be two of the most popular ORMs.
ORMs help you to think about your data as objects in your domain, instead of thinking about tables and fields and rows, so it abstracts the technical aspect of persistence and gives you a more model-driven approach while you are writting software.
I use to read a lot about domain-driven design as an architectural guide, but now here in stack overflow I've received many suggestions on using hexagonal architecture, all these patterns and practices help you to buidl better software, and I guess we will never stop learning. So yep, think about ORMs like artifacts to help you focus on more important aspects of your code rather than just making tables and querys. Hope it helps,
I'm interested in using an object relational mapper for an existing system which is a ASP.NET client, ASP.NET Web Services middle layer, and with an Oracle back-end. All database access is done using stored procedures and no SQL is allowed in the web services. I've been investigating NHibernate, Telerik's OpenAccess ORM, and the Entity Framework. I titled this "segregated" because the database is pretty tightly controlled by the DBA's. They also control the database design and reworking the database for adequate normalization (for the object model) is pretty much out of the question. Also, allowing the tool to create any of the SQL is also out the question.
My question is: Given these constraints, which of these tools would allow the best integration for this sort of environment?
None at all.
You're not going to be using 99% of the functionality of an ORM by having everythign done in Stored Procedures.
Probably better to use a Micro ORM like ServiceStack.OrmLite, or Massive, etc...
But looking at any full fledge ORM like NH, LightSpeed, EF, is complete over-kill and will just create more complexity for 0 gain.
Implementing your data access with stored procedures entirely does not mean that you won't gain any value by using an ORM. It just means that you will probably not use some of its benefits.
As for the ORMs you have evaluated, you have probably noticed already that:
All of them support Database First approach, where you can just create your model after the database is already defined, so you won't have to interfere with the DBAs work in any way but to ask for credentials
Entity Framework and OpenAccess provide visual representation of your model out of the box, while NHibernate doesn't
OpenAccess and NHibernate support Oracle, while with Entity Framework using Oracle is not so straight forward
The stored procedures support in Entity Framework and OpenAccess is much more sophisticated than in NHibernate. In OpenAccess you can even map a stored procedure to more than one results set.
I hope that helps.
Let me get this right. Your constraints are:
You have to use an ORM
You cannot modify the database in any way.
You can only use stored procedures.
I think I agree with #Phill. A full blown ORM is overkill when you cannot use it's functionality.
BTW, I once worked on a system like this where the DBA's ruled the roost and mandated only procedures to access the data. Nightmare.