I use visual studio 2005 , but recently I've heard that there is a new technology which called entity framework .. should I move on and use it instead of using the usual SqlDataReader !!
the most important thing to me is the performance , note that I get the data from the DB using DataReader and return it as a generic List ..
any suggestion .. thanx :)
The SqlDataReader and the Entity Framework are two completely different approaches to access your data. With SqlCommands, you yourself write the SQL queries. With an O/R mapping technology such as the Entity Framework, the relational database structure is mapped to objects whose properties you access, e.g. Linq to Entities. Note that the O/R mapping approach is not about speed.
If you are in VS 2005. I think you can't use Entity FrameWork. For that you required 2008 and .NET 3.5 SP1. Entity Framework has some issues. If you are going with Entity Framework; go with Visual Studio 2010 and .NET 4.0. This will be a better option.
Latest update from Scott Gu
If you want to switch to Linq to Entities then yes, you will need VS2010.
Or you can stay with VS2005/2008 and use nHibernate or similar framework.
But none of those ORM tools is (primarily) about speed, so it may not be the right thing for you.
The reasons for switching to an ORM framework would be to use a more OOP approach, ie to replace your generic list.
Look through a few demos/walkthroughs to decide if it is something for you.
I'd recommend to write up your requirements, then identify the options, evaluate each option with some tests that are meaningful for your requirements (e.g. ease of use, speed, etc.), and finally decide. With some smart design and implementation choices you might even be able to switch between some of them with relatively limited effort at least at the beginning.
The Entity Framework is certainly an option. I'd recommend to also include NHibernate and in particular fluent-nhibernate in your investigation. Good luck!
If you consider performance, see here
http://toomanylayers.blogspot.com/2009/01/entity-framework-and-linq-to-sql.html
http://blog.codefluententities.com/2012/06/05/codefluent-entities-performance-comparison/
Traditional ADO.NET (without ORM) is the fastest way. If efficiency is a key issue then better stay with "SqlDataReader".
Writing the queries yourself still beats any automatic process performance-wise. Entity framework makes the data layer more abstract, which improves portability and readability.
Related
I want to develop a C# <-> Database application. I've considered using a ORM creating me classes for transparent access to whatever database I want to connect to.
I found nHibernate. But this seems very heavy and complicated to configure.
My question: Is something out there that is lighter than nHibernate?
Thanks,
Andre
Edit: Love your answers. Nearly want to mark everyone as my favourite :)
You may take a look at Linq to Entities which integrates nicely with Visual Studio.
One of the easiest ones I've used is http://www.subsonicproject.com/
I found Lightspeed really easy to configure and use (much quicker than nHibernate). The express edition is limited to 8 mapped entities though so it is likely to cost you some money.
You can look at this set of posts "Build Your Own Data Access Layer" - it ends up building a lightweight ORM (and was written by one of the nHibernate contributers, Davy Brion).
From microsoft there are EF (entity framework) and Linq2Sql, though not sure that EF constitutes lightweight. See this comparison of EF and nHibernate (biased, as the writer is a heavy nHibernate contributor).
nHibernate is not complicated to configure. But I agree that it's sometimes too much for simple applications.
When I don't use nHibernate, I use simple ADO.NET objects.
When I don't use nHibernate, it's because ORM will be counter productive.
Given that I'm very good with SQL and c#,
Should I learn another layer on top like NHibernate ?
Is NHibernate just a library (that stores in a Database)? Or it's a service?
Should I use NHibernate or ADO.NET Entity Framework?
If you think I should learn/use an ORM, give me your top reason.
You should use an ORM as long as you need to convert database data to and from business objects, since it will save you a lot of work and will allow you to focus on your application logic.
NHibernate is a .NET library that does just that, mapping .NET objects to database tables according to how you configure it. In this sense it is the same as the Entity Framework, only that EF is already embedded in the .NET framework and NHibernate is a separate assembly that you must reference in your project.
Last but not least, if you use SQL Server you should add LINQ to SQL to the list of possible ORM candidates, it is simpler that EF and for many scenarios it is more than appropriate.
It depends on your applications.
NHibernate is a library. So it's a DLL.
Depends on what you want. NHibernate is based on Hibernate which is battle tested.
It doesn't matter how good anyone is with SQL or C#. There is a fundamental gap with the tools when dealing with SQL and C#. Aside from all the other productivity boosts that I've had when I learned to Stop Worrying and Just Use an ORM, I found only having to deal with C# most of the time has helped greatly. I have far fewer impedance mismatches in my work now and I do believe that contributes to fewer bugs.
Less code you have to write is less code you have to maintain. ORMs allow you to worry less about certain details so you are free to concentrate on higher level tasks.
No, I tried Fluent NH and Castle Active Record and Spring Framework NH Extensions but they all obscure basic operations and make things less visible. Start using native NH, then add a layer after a year.
Yes, NH is a library, not a service. But the way you use it in your code makes it feel almost like a service (e.g. a data repository service)
I tried EF and found it nauseating so I would go with NH
For OLTP-like systems, ORM is the way of the future. Not using ORM for me is like not using unit-tests or programming in non-OOP language.
Probably, but it depends on what kind of applications you normally write.
NHibernate is primarily a DLL, but there is more to it than that.
NHibernate (Read this for more details: NHibernate, Entity Framework, active records or linq2sql)
My top reason would be so you can use Linq. Right now, you pretty much need an ORM to use Linq.
Unless it's a very small application, then the answer is 'yes'.
Library.
I hear people swear by the EF, but I'm very leery of it. I also don't like tying myself to all Microsoft technologies. NHibernate would be my suggestion.
First, you don't want to go through the time and headache of writing all the SQL and classes and such; it's just not worth it. Second, it allows for greater ability to switch from one RDBMS to another without having to change much code. Third, it'll give you more control in the future in terms of database abstraction and such.
I've been programming in C# 2.0 WinForms for a while now. I'm starting to get into ASP.NET and the new MVC framework and the new features of C# 3.5. I've only read a little on LINQ to SQL but have made a few test apps to try it out. In my WinForms apps, I usually had some sort of data access layer, and wrote all the SQL myself. Of course, if something can do that CRUD for me, I'm all for it.
I followed the tutorials on the www.asp.net/mvc website and did both the Entity Framework example and the LINQ to SQL example. So far, they both seem pretty similar. LINQ feels more like SQL, but the Entity Framework feels more like C#.
My questions are:
Is one method better than the other?
What are the benefits of one over the other?
Is it possible to see the SQL that is generate when using either of the methods?
Since I'm new to the ASP world, are web developers leaning on one side?
2: LINQ-to-SQL has the benefits of being simple (but still well engineered) - but the downside of being simple ;-p
LINQ-to-SQL only works on SQL Server (Entity Framework is pluggable; 3rd party variants of LINQ-to-SQL like DBLinq cover some other providers)
Entity Framework supports more abstraction between the data (storage) model and the object model - LINQ-to-SQL is literal table/column => class/property[|field]
LINQ-to-SQL is actually more "complete" in the stuff it does do:
EF doesn't support UDFs
EF doesn't support things like sub-expression invoke (for custom expression trees)
EF doesn't support some "obvious" methods like Single()
EF doesn't have some of the TSQL optimisations that LINQ-to-SQL uses
Basically EF at the moment is a bit more of a "v1" (or even "v0.9") product. However (and importantly) - EF is likely to have a proper next version in .NET 4.0 etc, where-as LINQ-to-SQL is going to see a lot less change. It is still being maintained, but famously Microsoft have chosen Entity Framework as the flagship product (rather than co-evolve both products essentially into each-other). You should think about the long term plans.
At the moment, I'm very happy to use LINQ-to-SQL, but EF is on the long term... so I'm using repository etc to hide some of the gory implementation details - a bit of a leaky repository, but pragmatic.
3: With LINQ-to-SQL, assign a TextReader to dataContext.Log; Console.Out works well - or I have one that writes to the trace.asax. With EF, ToTraceString.
4: I suspect it breaks down a lot by complexity. People using SQL Server with simple models, or who are happy to have a storage model that shines into the object model tend to be using LINQ-to-SQL at the moment (from what I see). People with more complexity and other databases tend to use NHibernate ;-p And then some EF. I'm wondering how much this will change when EF is next released in .NET 4.0...
Use the one that feels best for you, your team and your project. It doesn't really matter how you access the data, as long as you access it.
You could use plain old ADO.NET if you want.
with LINQ2SQL, Entity Framework in the market, does it make sense to use Enterprise Library data access application block to design Data Access Layer(DAL)?
thanks.
That's like asking "Should I use a Dremel Rotary Tool or an Ingersol Rand industrial sandblasting rig?"
Can you describe what your application does and where it'll be used?
It really depends on what you are doing.
A lot of what I am writing is to existing stored procedures and other similar items. I find that SqlHelper from the Application Blocks fits my needs quite well, and haven't been compelled to change.
I have been using linq2sql and it is great. That said it can tie you with sql server (although there are third party implementations that enable linq 2 other database systems). Entity framework is rather new, but doesn't have the same restriction.
I recommend to go with either of those.
The question header is clear, i want to know why its different and why, when to select it for my project?
I wrote a blog post on this a while ago. In short, it takes a fundamentally different approach to ORM than Hibernate, ECO, and the other ORMs that I have looked at. You may think this approach is better, worse, or unimportant, but if you look deep enough it's hard to dispute that it is different. But don't take my word on it. If you're really interested in this subject, I strongly recommend reading this technical paper and this interview in ACM Queue.
This is probably not the answer you are looking for but I dont think you should use it in your project. It is very young and not very complete. Wait until the next version comes out.
If you insist on using Entity Framework there are a few good things about it. A nice one is the way it allows for complex mapping in a very simple way. And of course because it is a microsoft technology the IDE integration is nice.
But like I said, I tried it and I dont beleive it is ready for real use.
Anyway good luck at your project
ADO.NET is not an ORM.
Basically the difference is the level of abstraction used in each one.
With ADO, you basically query the DB and use the results as objects, is like a bridge between the RDBMS and your objects.
You model your DB and then you create object from that model. That's why it is an Entity Framework ( db entities )
ORM are not for querying or represent database records as objects ( although that's how everyones uses them anyway - me included - ) but a way to persist your object model into a relational database.
They are Object to Relational Mapping ( not Relational to Object Mapping )
So, you choose one or the other, when you have a domain ( object ) model and you want something to persist it ( to a RDBMS ) or when you have a entity model and you want to use it as objects in your app.
From what I've read, it has good support for WCF remoting/binary serialization, which is something many ORMs don't support very well (if at all). It might be worth looking into if you want to create a rich client/server/remoting app with ORM on the client side.
What different? It didn't learn from all the other ORMs.
Here are the issues I've been tracking for InfoQ
Does LINQ-to-Entities really return different results depending on previous queries?
Working Around Entity Framework's Large Data Model Issues
No Change Tracking for ADO.NET Entity Framework 2010
And this tool is a must-have if you do decide to use it.
Meta-data Synchronization Tools for LINQ to SQL and ADO.NET Entity Framework
Some of the best talent in the ORM world in .NET seem to be working on projects such as NHibernate (free-open-source; I use it) and LLBLGen Pro (commercial).
NHibernate is the reigning standard for enterprise-quality full-scale multi-vendor ORM. NHibernate is also the reigning standard for a pure implementation of ORM, permitting you the developer to write domain models completely independently from the NHibernate infrastructure, and completely eliminating code-generated classes.
NHibernate may look scary at first. But it is actually fairly friendly once you work with it a bit, and work has been underway since July to make NHibernate nearly configuration-free.