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.
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.
I just read this article about the Entity Framework 4 (actually version 2).
Entity Framework seems to offer a huge improvement over its first release. Thus, I have never ever used EF in any project, since I think EF is not mature enough in comparison to NHibernate.
NHibernate and its current contributions of FluentNHibernate and Linq for NHibernate by Ayende Rahien
My feeling is that Microsoft is solely trying to gain terrain it has lost in favor of NHibernate when the 2nd version of NHibernate came out. Nevertheless, my concerns are the followings (not in particular order):
Will EF4 tend to be less XML-verbose?
Will EF4 be compatible with underlying datastores other than just SQL Server?
What are the greatest benefits of going with EF4 instead of FluentNHibernate or NHibernate itself?
NHibernate is a great tool, I guess everyone agrees. Due to its predecessor Hibernate, we may easily find documentions and tutorials and sample applications to get acquainted with it. This is not the case for FluentNHibernate. Particularly as per the project I'm working on right now which demands that I investigate further about NHibernate and its options (FluentNHibernate for instance) in order to document the rules of usage and the best practices of NHibernate and FluentNHibernate technology. Thus, being handcuffed with VB.NET, being a C-Style developer, I can't find some syntax equivalencies in VB.NET for the examples provided, though I made my way so far.
I do believe that NHibernate is a best choice, but as a software consultant, I can't (don't want to) miss important technology changes, improvements and evolution.
Despite the bad comments I read about EF1, EF4 seems to be very promising. What you all think about both NHibernate and Entity Framework avenues? As for me, I am becoming puzzled with all that readings. I need you to bring back my head out of the water.
Thanks to you all!
I know almost nothing about EF, but a quick skim of the links provided leads me to believe that EF has no equivilent to Fluent NHibernate's Automapping functionality.
Edit: Some of the commenters pointed me to links indicating there is some automapping in EF, but it's not really clear if it's as powerful as FNH (for example, being able to automap collections of other objects).
Personally, I love being able to design POCOs in an OO manner, and letting the tool handle all the busy work of mapping to a relational database.
FNH still has the most powerful automapping capability, as far as I know.
Go to Fluent NHibernate Automapping for more info.
Will EF4 tend to be less XML-verbose?
In general, I have not seen any indication that the XML will be drastically different. Microsoft is providing a Fluent like interface to EF in v4, but it's an add on / separate download.
Will EF4 be compatible with other underlying datastore than just SQL Server?
It is compatible now and it will remain compatible going forward. LinqToSql is SQL Server only, but EF has never been SQL Server only.
What are the greatest benefits of going with EF4 instead of FluentNHibernate or NHibernate itself?
Honestly, there aren't many. There are little things here and there that are different, but in general NHibernate is still years ahead of EntityFramework, even in EFv4.
As a consultant, it is probably worth your time to become an expert in both NHibernate and Entity Framework. You will probably continue to see them both in the real world. Microsoft tends to have a short attention span when it comes to data access so it's not clear where Entity Framework will be a couple of years from now. Because it's from Microsoft, you can be sure that plenty of developers will use EF.
Take this with a grain of salt. I am not any kind of authority on ORM tools, but here it goes...
One of the biggest benefits that i see in EF is the GUI for mapping. IMO, this saves a lot of time, but is probably the reason why EF XML mappings are so verbose. They're not made to be dealt with manually, unfortunately. Whether it will change or not i don't know. What i do know is that the GUI that EF provides used to be very flaky in previous releases. And i still hear about people complaining that it isn't scaling well, especially on larger and more complex schemas where it just misses things and you end up messing with the mappings directly. My opinion is that XML maps will become less verbose as EF matures. You also have the fluent mapping support in EF, which is also helpful. Finally, another big thing is the ability to change code templates that EF generates, that is if you favor database-driven design instead of design-first approach.
Another benefit is that it comes from Microsoft and they have enough dough to make this a really dope framework. It has grown tremendously in the past few years. I think it'll be on the same ground with NHibernate in a little over a year. As of now, I think NHibernate is a better choice. It's more stable and mature. Relative easy to configure and most importantly a better performer. I think if you design wisely, a move from one to another is going to be a piece of cake.
EF is just an abstraction. I believe there are providers for Oracle, so i don't see why there couldn't be more added as it grows.
I am really having a hard time here. I need to design a "Desktop app" that will use WCF as the communications channel. Its a multi-tiered application (DB and application server are the same, the client goes through the internet cloud).
The application is a little complex (in terms of SQL and code logics) then the usual LOB applications, but the concept is the same: Read from DB, update to DB, handle concurrency etc. My problem is that now with Entity Framework out in the open, I cant decide which way to proceed: Should I use Entity Framework, Dataset or Custom Classes.
As I understand by Entity Framework, it will create the object mapping of my DB tables ALONG WITH the CRUD scripts as well. Thats all well and good for simple CRUD, but most of the times the "Select" is complex and it requires a custom SQL. I understand I can use Stored Procedures in EF (I dont like SP btw, i dont know why, I like to code my SQL in the DAL by hand, I feel more secure and comfortable that way).
With DataSet, I will use my custom SQLs and populate on the data set. With Custom classes (objects for DB tables) I will populate my custom SQLs on those custom classes (collections and lists etc). I want to use EF, but i dont feel confident in deploying an application whose SQL I have not written and cant see in the code. Am I missing something here.
Any help in this regard would be greatly appreciated.
Xeshu
I would agree with Marc G. 100% - DataSets suck, especially in a WCF scenario (they add a lot of overhead for handling in-memory data manipulation) - don't use those. They're okay for beginners and two-tier desktop apps on a small scale maybe - but I wouldn't use them in a serious, professional app.
Basically, your question boils down to how do you transform your rows from the database into something you can remote across WCF. This means some form of mapping - either you do it yourself, using DataReaders and then shoving all the data into WCF [DataContract] classes - you can certainly do that, gives you the ultimate control, but it's also tedious, cumbersome, and error-prone.
Or you let some ready-made ORM handle this grunt work for you - take your pick amongst Linq-to-SQL (great, easy-to-use, flexible, but SQL Server only), EF v4 (out by March 2010 - looks very promising, very flexible) or any other ORM, really - whatever suits your needs best.
Other serious competitors in the ORM space might include Subsonic 3.0 and NHibernate (amongst many many others).
So to sum up:
forget about Datasets
either you have 100% control and to the mapping between SQL and your objects yourself
you let some capable ORM handle that (Linq-to-SQL, EF v4, Subsonic, NHibernate et al) - which one really doesn't matter all that much, i.e. it's also a matter of personal preference and coding style
I can't advocate datasets, especially in an SOA environment like WCF - it'll work, but for mostly the wrong reasons. They simply aren't portable, and IMO don't really "work" over service boundaries. Of course, IMO they don't work in most other scenarios too ;-p
So then it comes down to how much plumbing you want to do. Most ORMs will create WCF-serializable types for you; personally I'd use LINQ-to-SQL at the moment; it is both simpler and more complete than EF, although EF 4.0 is meant to be much better than EF in 3.5sp1. You can use custom TSQL (via ExecuteQuery, which still does the mapping back to objects), but I tend to use either SPROC (for complex queries) or LINQ-generated queries (for simple requests).
Writing the types yourself is fine too, and will work with NHibernate etc. So many options.
While EF works with WCF and sounds very promising, you should consider the effort to get on speed with it. Especially when doing some non trivial stuff, the designer in VS2008 can't open the model anymore and you have to code your model in xml.
Also keep in mind that EF works on a very high abstraction level. Because of the law of leaky abstractions its not all that shiny as it supposed to be :)
The other way round that means, you have to deal with very crazy and hard to read sql statements sent to your database when it comes to troubleshooting / performance issues.
When I last worked in programming, we were trying to move away from DataReaders and the traditional ADO.NET API toward Object Relational Mapping (ORM).
To do this, we generated a DataContext of our DB via sqlmetal. There was then a thin data layer that made the DataContext private, and any code needing to access the database would have to use a public method in this thin data layer. These methods were basically stored procedures; they would perform queries on the database via LINQ to SQL.
Is this a common approach today? I mean, is everyone whose using the .NET 3.5 framework really running sqlmetal in their build process, or what? It almost seemed like a hack at the time.
Basically, I'd like to know if LINQ to SQL and sqlmetal is what to expect if I'm go to write a DAL today at a .NET 3.5 shop that doesn't employ a third-party, open-source ORM.
It is still considered best practice to have some sort of data access layer. Whether this is best achieved with a ORM is a heavily debated issue. There is one faction that generally argues that ORM's are the way to go. Another faction argues that stored procedures and database centric is the best route.
Also, this may not be exactly the poster you meant, but it similar (and also the one in my cubicle)
http://download.microsoft.com/download/4/a/3/4a3c7c55-84ab-4588-84a4-f96424a7d82d/NET35_Namespaces_Poster_LORES.pdf
Your approach is good. I currently use Astroria services (ADO.NET Data Services). There was a nice introduction in MSDN Magazine about this.
I also like the new PLINQO (requires CodeSmith Tools though). This is very slick in my opinion.
When I have such a DAL (service layer), I just consume this service from my client application (Silverlight or ASP.NET MVC).
I think it depends on your use but I'd say with such a thin data layer as you explained that would be your DAL. Most projects will build another layer on top of that mainly for edit/create logic and maybe some stitching logic for gets.
For most of my projects I design it like this.
Repository holds the instance of DataContext and exposes some basic add/delete methods
ProductRepository : Repository exposes general queries (IQueryable)
StoreService uses an instance of different repositories like ProductRepository, SalesRepository and handles all logic for creating something like a product.
So something like...
StoreService.CreateProduct(/* properites */)
This would return some sort of result class.
The best data layer is the one that is plain and simple and gets the job done without any bells any whistles. I have used the technologies you mentioned and written about them here:
The Only Pattern for Data Access is - There Are No Patterns for Data Access
This very site uses LINQ to SQL, so take that as you will.
Officially, Microsoft is supporting Entity Framework over LINQ to SQL in terms of new development. However, there's a vocal group of people who think EF is the wrong way to go. LINQ to SQL will still be around for some time, and is a very decent ORM, if somewhat limiting in terms of which DB backend you can use.
I would recommend LINQ as a great starting point for your ORM. If you need better, look into EF and/or NHibernate.
"Is this a common approach today? I mean, is everyone whose using the .NET 3.5 framework really running sqlmetal in their build process, or what?"
The people I know using the 3.5 Framework (and that's just about everyone) - the vast majority - are still using NHibernate. Version 2.0 is a very nice OR/M. I started using it on a recent project and it cut my data access code down significantly, to the point where I really don't want to use anything else in the future. And the Fluent NHibernate API is making some headway for folks who don't like the XML mapping.
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.