There are plenty of questions on here that ask 'what ORM should I use with x and y' but I didn't see any that specifically asked how to pick one. Related: Why should you use an ORM?, What ORM should I use for a ASP.Net MVC project?, Are there good reasons not to use an ORM? and more.
There are a lot of ORMs out there in the world. I'd like to get an idea of how to compare them. I've heard about things like active record model and domain model among others and I'm not sure what those mean. So what are a good set of criteria I can use to compare one ORM to another?
Our environment, in case you're wondering, is C#, MVC, SQL Server.
(I tried to answer in a non-.NET specific way when possible.)
The most important criteria for choosing an ORM are your business requirements.
I would say another important criteria is your belief in the future sustainability of the ORM. Microsoft has a tendency to change their data access technology every two years or so, so I would say Entity Framework's future is unclear. NHibernate may follow the same path as NUnit - when Microsoft released MSTest, NUnit languished for a while, but now NUnit has momentum again since Microsoft is mostly neglecting MSTest. You have to reach your own conclusion here, right now Microsoft appears to be giving Entity Framework some love, yet as far as I know it still doesn't handle enums very well and I haven't heard when that may change.
Another criteria is whether you have a preference between open source technologies or technologies from Microsoft or commercial third party technologies.
At some point, the features of the ORM will matter. You may need to prototype your scenario with multiple ORMs to determine if the features (and/or performance) of the ORM match your requirements. NHibernate is the most feature rich ORM in the .NET space.
Do you need to support a certain database vendor? Pick an ORM that supports the one you care about. SQL Server is the most widely supported database vendor in the .NET world.
Do you have a preference between code first or database first design? Pick an ORM that supports the one you care about.
Do you have a preference between active record vs. repository vs. something else? Pick an ORM that supports the one you care about.
I answered the question linked below about choosing a .NET ORM partially by providing links to all the times people asked which .NET ORM they should use on StackOverflow. There is a lot of value that can be gained from reading those other answers.
NHibernate, Entity Framework, active records or linq2sql
There is no one right answer nor one correct set of criteria for choosing. Your business requirements are the most important ingredient to consider.
Related
Because of specifics of my current project, I have to keep using .NET 2.0. Are there any Entity Framework-like ORMs for .NET 2.0?
I'm absolutely OK with non-LINQ interface. Syntax like users.Where(u => u.Age > 100).Count() is fine.
I need to use DB-first approach: I already have a DB with about 30 tables and just considering the ways of simplifying work with it. So, I'd really appreciate if it's possible to generate the required code from existing DB.
It's also OK if it won't generate all the required code but provide the way to describe DB structure manually (using attributes, for instance). Basically, I just want to be able to build more or less sophisticated queries without messing with real SQL, SqlParameters and DataSets/DataTables with all these int.Parse(row[12].ToString()) (that's a legacy code I'm trying to get rid of)
Also, that would be great if I'm be able to "override" some particular "queries" with calls to existing stored procedures.
The most important is p.2 - DB first. Is there anything of this kind? Or am I absolutely wrong with my thoughts? Will appreciate any ideas.
Your best option is to check out NHibernate. Many (most?) people consider consider it more feature complete and powerful than EF 4.1, plus there are plenty of resources here on stackoverflow and the rest of the web to guide your development process.
Be sure to look into Fluent NHibernate to make mapping from your database to C# objects easy. The alternative of editing XML files is complex, clunky, and time consuming.
Note that you might need to use an older, but still completely functional, version of NHibernate that is compatible with .NET 2.0 (I think, but am not positive, that the more recent versions require .NET 3.5).
There is plenty of available ORMs but some of them are commercial (LLBLGen Pro). The good choice for you is probably NHibernate 2.1 (I think NHibernate 3.x requires .NET 3.5).
You should also thing about moving forward to a newer .NET version. Starting a new development on .NET 2.0 should be avoided and involving a new technology to existing old code base IMO spoils application's architecture and maintainability.
Edit:
So, I'd really appreciate if it's possible to generate the required code from existing DB.
The most important is p.2 - DB first.
ORM and code generation are two different areas. DB first doesn't mean code generation - it means mapping to existing database without needs to change the database. It is not point of ORM to generate code for you. The point of ORM is to allow you to map DB to classes and abstract querying. If the most important point for you is code generation you should look for something else then ORM. NHibernate doesn't have such code generation included but there are some additional projects which add similar features.
When Linq-to-Sql was first released, I used it quite a lot for small and medium sized projects where a true multi-tier architecture wasn't required.
NHibernate, Small Middleware, Overkill
Where I work, we now almost exclusively use NHibernate for true Domain Driven development.
I'm working on a small temporary (a lifetime of probably a year, maybe less) middleware component where NHibernate feels slightly overkill in terms of configuration and keeping the entities up to date. Especially because I haven't got any control over the DB, it sometimes changes, and it's a little bit "legacy".
Some changes were recently made to the DB, and the NHibernate mappings are not very complete.
Linq-to-Sql? Or EF?
I thought it might be easier just to rip out the IRepository implementation I have and replace it with a Linq-to-Sql implementation. Then I can just use lambdas for my simple queries, and just drag and drop the tables in.
RAD But Dead?
In this scenario the RAD elements of Linq-to-Sql make sense. But it's essentially old technology. Should I not use it? I've never used the Entity Framework. Should I use that, is it as easy and quick to use?
cheers
Is it still OK to use Linq-to-sql?
Yes. It is OK to use any technology which allows you delivering the product in time, with required functionality and quality. You can still find projects using ASP, ADO, VB6. One reason why Microsoft technologies have very hard time in many international corporations is that their products have very short lifetime. Linq-to-sql was on the market less then 2 years and was deprecated by Microsoft but companies / community argued about that and Microsoft changed their strategy little bit. Linq-to-sql doesn't have new features but it is still supported and a fully functional technology.
Will Linq-to-sql or EF solve your problems?
It depends. Perhaps yes and perhaps no. Don't believe to marketing announcements about RAD. Sometimes I feel that people think that RAD is about designer. No. Tools supporting RAD are about well defined API which is easy to understand, easy to use and doesn't contain unexpected behavior (Principle of least surprise) - you will use the API to quickly prototype the application but it still requires understanding and practice. NHibernate's mapping is still prototyping when you compare it with manually doing whole data access. We can even follow the basic rule of good framework: Easy things are easy to do and hard things are possible. That is something that NHibernate accomplish much better then EF or Linq-to-sql.
If you know NHibernate but you don't have any real world experience with EF or Linq-to-sql, you can be sure that neither Linq-to-sql or EF will increase your productivity in first one or two projects where you use it. If you don't have too much experience with NHibernate changing to EF or Linq-to-sql will probably don't cause temporary lose of productivity.
I also don't think that EF or Linq-to-sql will generally help you in situations where database changes. As I remember Linq-to-sql designer doesn't have update mapping functionality at all and because of that it is very often used completely without designer so you must still manually modify mapping. EF's updating model from database can be helpful here but it is not a silver bullet. Some updates can require manual modification of EDMX file (huge XML).
At last be aware that NHibernate's mapping features are much more powerful especially when working with legacy databases. Linq-to-sql's mapping features are very limited, it is mostly 1:1 mapping of tables to classes with some exceptions (basic TPH inheritance). EF offers more complex mapping features but it somehow expects a correct design of the database.
If you (and your coworkers) are comfortable with NHibernate, then it should be just as RAD as Linq to SQL. There's no reason not to use L2S as long as you understand it's not going to get much in the way of updates and improvements from Microsoft, but in my experience if you know how to use both frameworks already, no need in re-doing the work just because L2S might be a little more RAD
Some good discussion on NHibernate vs L2S/EF
Entity Framework vs LINQ to SQL
MS Entity Framework VS NHibernate and its derived contribs (FluentNHibernate, Linq for NHibernate)
in your specific case, you should go with technology you are most comfortable with. Though Linq2Sql is relatively straight forward - and build right into the language - it does have a slight learning curve and its own set of gotchas!
What is CSLA Framework and Its use ?
My Opinions From My Experience w/ a 1.7M LOC code base:
CSLA is intended for a distributed application/database environment. This is why the basic business object is and does everything, for example it's own data persistence. An object (and everything remotely associated w/ its state) is intended to be serialized, sent to a different application and/or data server and work.
If the above is not a problem you need to solve, CSLA is overkill, big time. Our development team regrets having committed to CSLA.
Juggling all the CSLA balls in a complex Windowed UI is tough. We have multi-tabbed screens (which may in turn open sub-screens) that, unless you follow the "left to right, top to bottom" flow of data entry, and click save often, ends up putting and/or fetching incomplete data to/from the database; or dropping data altogether that you just entered. Yes, our original coders are at fault, but so is CSLA... It just seems that there are so many moving parts to enable, control, and coordinate CSLA features. It's like having to deal with all the dials & switches of a fighter jet when all you really need is something more like a Cessna 152.
You will write lots of custom code to enable the CSLA features. For example CSLA will never be confused with object relational mapper (ORM) tools like Hibernate and Entity Framework. Our SAVE() methods are non trivial, so are the trivial ones.
Encouraging the use of code generators compounds problems. We used CodeSMith to generate classes from data tables. So we end up with code that has a 1-1 correspondence of table to c# class. So you must write all the code to handle dataStore to your "real" objects.
Data store/ and fetch is very inefficient w/ CSLA. Because of the Behemoth, monolithic BusinessObject-does-all-and-knows-all centric paradigm, objects end up doing a one-object-at-a-time data fetch and instantiate. Collections of composite objects significantly compound the problem. A single "get this object" always results in a cascade of separate data fetches (one or more for each individual object) to instantiate the entire inheritance & composite relationship chains. Its known as the "N+1 query problem." Oh, and fetching data ALWAYS results in a new object being created, even if we're only updating an existing one. No wonder our more complex screens are FUBAR.
It allows you to architect your application with solid object oriented principals and a good seperation of concerns.
Yes and no. Mostly no.
The BusinessObject handles it's own data storing. That is anti separation of concerns.
"It allows you..." well, yeah - so does a blank text editor screen, but does not force or encourage you like the MVC.NET framework does, for example. IMHO, CLSA provides absolutely zero benefit for ensuring that the code you develop with it follows "solid OO principles". In fact coders w/ weak OO skills (the majority, in my experience) will really stand out when using CSLA! Woe betide the maintenance programmer.
CSLA is the poster child for the solid object oriented principle favor composition over inheritance. CLSA code is untestable. Because an inherited framework BusinessObject is, does, and needs everything, all at once and every time, it's not likely that you will be able to get much test coverage. You can't get at the pieces because everything is tightly coupled.The framework is not amenable to dependency injection. It is an iron curtain of code.
Your code will be difficult to debug. Call stacks get very deep and as you get near the center of the sun so to speak, everything turns into reflection - "what *&^# methods just got called???" And you simply get lost. period.
EDIT 7 Mar 2016
What more insight can I add after the original post? Two things, perhaps:
First, It feels like CSLA has some promise. If we knew how to juggle all those moving parts together. But CSLA is so enigmatic that even things we have done right are corrupted over time. IMHO without a very strong team-wide CSLA wherewithal, any implementation is doomed. Without a vibrant "open source" of technical references, training, and community it's hopeless. In almost a decade our CSLA code, in my final analysis, is just compounding technical debt.
Second, here is a recent comment I made, below:
Our complexity often does not seem to fit in the CSLA infrastructure
so we write outside of the framework. This and cheap labor results in
rampant SRP violations and has me hitting brick walls managing dynamic
rule application, for example. Then, CSLA parent/child infrastructure
propagates composite object validation but we don't always want c/p
relationships, so we write more validation and store code. So today
our CSLA implementation is inconsistent & confusing. Refactoring to
more-better CSLA will have profound domino effects. So after that
initial injection CSLA is essentially abandoned.
end Edit
CSLA is business object framework that allows you to easily create business objects on top of a data layer. It allows you to architect your application with solid object oriented principals and a good seperation of concerns.
I would highly recommend you read the CSLA book by Rocky Lhotka called Expert C# 2008 Business Objects. That will not only teach you about the framework but also teach good software architecture principals.
You can grab the book here on Amazon
I suggest reading the What is CSLA? page, and browse through the CSLA .NET FAQ site.
For the latest published information check out the Using CSLA 4 ebook series.
In reply to #radarbob https://stackoverflow.com/a/10922373/261363, hope I won't regret this and start a flame war.
Our team has been developing a couple of LOB applications with CSLA. From my experience on writing green field apps with CSLA and maintaining existing code here are my replies to your points.
The BO is not suppose to do it's own data persistence, you will have a Factory that will handle all data persistance, for example using a ORM to map to Models that are later on saved.
Sorry to hear that, I make sure I study the framework documentation and write at least one toy application before committing to a existing code database. Furthermore you can even download and browse the CSLA code.
You have BO -> Portal -> Factories that should not be very complicated the existing CSLA examples go a long way on explaining what is happening on each level.
CLSA should never be confused with a ORM
As you should, business object are rarely mapped to one table and thus require a bit of work when saving. In the case they are mapped to one table to you use something like AutoMapper to map your BO to your POCO in 1 line.
Look into CSLA Commands, also is nothing stopping you from keeping your BO as small or big as you want as long as you keep in mind that they are not the same as the POCO's that you will persist.
In a project we worked on we where able to easily test BO to ensure that the business logic was correct. Because of the nice separation of concerns we tested our Factories in isolation to make sure that business objects will be persisted accordingly.
At one point I was able to easily persist part of my BO's in MongoDB so the application was running on a hybrid database MSSQL and MongoDB without having to even change one line of code in my business objects, all I had to do was to update the factories to use Mongo instead of the current ORM.
Hope this addresses all your points in a fair manner,
Regards
CSLA: Component-based Scalable Logical Architecture
A paragraph in a nutshell that described CSLA to me from the website was this:
CSLA .NET enables you to create an object-oriented business layer that abstracts and encapsulates your business logic and data. The framework ensures your business objects work seamlessly with all .NET interface technologies, including WinRT XAML, WPF, ASP.NET MVC, ASP.NET Web Forms, WCF, asmx services, Windows Phone 7, Silverlight, Windows Workflow and Windows Forms.
Why you might use it:
Business rule management. Once you learn the business rule system, it provides a way to enforce business logic in a tidy package. If you have an object with child objects that need to report Validation to the parent most level, there is a way to handle that. (see http://www.lhotka.net/weblog/CSLA4BusinessRulesSubsystem.aspx for more information on the rule system)
You have business objects that you need to support N-level undo? A CSLA BusinessBase has a baked in property management system (like dependency properties) for functionality like N-Level Undo (it is actually completely implemented.) (This also ties into the business rule management. You can fire validation when a primary property changes, or you can change a property based on the value of another property.)
Data portal management. This one was an interesting concept. If I need to execute data operations locally, CSLA is configured for this out of the box. I can also stand up a WCF service that references my business object libraries, and use a few lines of configuration to make a WCF endpoint to manage data operations. The WCF service is a part of the CSLA framework. It was neat to see this in action. Other scenarios? Sure! Your business object library doesn't need to change, the DataPortal class determines if it needs to execute remotely or locally, according to your configuration.
CSLA does force you to use a few mechanisms that may not feel natural at first. I think that is somewhat true of any pattern you choose to implement. However, when it comes to the challenges of implementing Service Oriented Architecture, CSLA offers a lot. Yes, you are going to have an architect level developer authoring some of your libraries. However, if you're building an enterprise class application, shouldn't you be doing that already?
CSLA, when architected correctly, is testable. We use the repository pattern to replace out the actual dal with a mock layer and test both by specification (using NUnit/SpecFlow) and in a unit fashion when appropriate.
As far as support, including Rocky himself, there is a community of contributors that ensure things like CSLA.Net for Xamarin become a reality. There are consultancies that know CSLA and use it on a regular basis depending on the scope of work (and no, not just the consultancy for which I work.)
All things considered, CSLA may not be for you. Like others have indicated, read the site and the books (especially Expert C# 2008 Business Objects.) Ask questions, as the CSLA community tends to give quality advice.
CSLA is described in detail here. The new book is a great starting point. As a great compliment to the book I would recommend checking out our CSLA 3.8 templates. Rocky recommends using a Code Generator, and we have the leading set of templates, that will get you up and running in no time.
Thanks
-Blake Niemyjski (Author of the CodeSmith CSLA Templates)
I was surprised to find a public letter proposing a vote of no confidence in the entity framework (see http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/)
Would the reasons stated in the letter keep you from using the current version of the entity framework? Would you rather wait for v4.0? Or rather use another ORM?
The current version of EF is definitely not perfect, and has lots of gotchas and drawbacks. I probably wouldn't use it right now - but the upgrade path to EF v2 (or is it EF4?) sure looks pretty rosy!
complete persistence ignorance - you can use your straight up POCO classes
deferred loading configurable as an option
much improved designer with support for pluralization/singularization (even in multiple languages!)
ability to do "domain first" design and create database from your model
ability to have self-tracking entities across multiple layers that allow you to send data to the client and get back changes and apply them to your entity context
All in all, EF v2 looks very promising and I'm very eager to give it a serious spin. If it really keeps all the promises out there right now, it's definitely a winner!
Check out the ADO.NET team blog for a flurry of recent blog posts on EF v2.
Marc
Another ORM.
Don't get me wrong you should get flamed with responses, but currently only nHibernate is functionally complete.
I'm a TDD fan, so want an easily testable POCO ORM solution. If that's your bag then EF3.5 is out. EF4.0 is introducing it (http://blogs.msdn.com/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx) , but it still has at least 1 big drawback -> doesn't support inheritance.
NHibernate is more complete, but EF could be easier to use. As ever, best tool for the job... but if it's an Enterprise-scale TDD developed app, go nHibernate.
Also -> there's a profiler that makes nHibernate dev much easier -> http://www.nhprof.com/
I tried using it for my current project, which basically involves rewriting our current mess of a data layer.
It just doesn't work.
First, if you're trying to base an Entity off of a View, the designer tries to force every NOT NULL property to be an entity key... which is pretty much never what I wanted. To work around that you have to edit the xml in at least two places, and do it every time you add an object because it refreshes and re-adds the EntityKey properties. Must specify mapping for all key properties in Entity Framework?
Second, when you are creating associations you MUST use every entity key - How can you make an association without using all entity keys in entity framework?
Those two things held me up for 3 days, then I went back to Linq to SQL and had it done in a couple hours. (Well, at least the part of the system I was struggling with... ) I don't know if those are in the Vote of No Confidence, but it's just not ready in my opinion.
Also with the lack of answers I got here on every EF question I've asked, I have to assume current usage is so low that getting help and support is going to be difficult... which is possibly the BIGGEST reason not to use something.
Let's hope the next version is better...
EDIT: OUr current plan is to stick with Linq 2 SQL (I have to finish a project by Friday) and then evaluate all the other ORMs to see if anything else is better. The other developer hates L2S for the record, but I've never had any major problems using it...
EF has some rich design time support, but I have to agree that nHibernate is the way to go, despite the learning curve. If you need to make something fast and don't care about TDD or serialization (which is a large weakness of all of MS's ORM offerings) go EF.
Well My experience of Version 1 was interesting. I wanted to use POCOs but it didn't support it. After reading around I came across some code from a bod at microsoft that did this.
It was a bit messy to generate the code but on the whole this part of the process was not so bad.
A real nasty part that I came across was the lack of Concurrency checking built in, for N-tier development. You have to manage this yourself which after looking at the problem was not so bad, especially if you want to hand back the versioning back to the client for user intervention.
Second nasty and absolutely stupid thing missing was the IN keyword for LINQ queries. Not supported and so needs to be worked around. I found a solution but was a real mess bringing in some other code that quickly patched up the omissions.
Would I use EF 4.0 (2.0). Yes, absolutely, why not? In fact on stage 2 I will be using this. It looks like it supports POCOs, it looks like my concurrency model will move straight across with no problems (basically delta copy stuff). Its all good so far and I hope this time round that the Big guys at Microsoft have seen the errors of their ways and provided a solution that works.
If your buying into entity development and the whole Concept Model first thing, then its the only way to go for a complete Microsoft solution. Although the stuff being done on the M language might eclipse the idea and move the whole modelling thing back to the Database.
If you not buying into the Entity stuff then I would strongly go Enterprise Library. Its a proven technology that works every time built on a solid code foundation and Database centric paradigm. I would also go this route if you think that Stored Procedures are the bees knees and like what they bring to the table.
If your feeling really exotic and feel a bit frisky I would go with a NO-SQL approach such as CouchDB. This however does take some getting used to. Its damn weird and feels really really wrong. But things get developed in super quick time and the solutions seem to be robust and faster than expected. I would not got for this type of solution though if your big into Normalization and think that it can be applied to a NO-SQL approach. The whole model needs to be shifted on its head and the application will be needed to be modelled in a way that is driven by the technology applied.
I find the CouchDB way a bit dirty and very very wrong. But it has so many compelling reasons to use it, that I think it will seep into the psyche of every programmer, and it will definitely go mainstream in the next couple of years.
My biggest gripe still with the whole Entity thing though even in the new version 4 is that there really has not been much thought into N-tier environments. It still got a feel about it being a 2 tier solution with a lot of boiler plate code still needed to be done by the end user (developer), to get it working in a robust and dependable N-Tier way.
I was listening to a podcast recently that was discussing at length the short comings of Entity Framework (EF).
But, their opinions may need to be taken with a grain of salt (by me), as from what I could gather:
These were folks that were ORM experts.
They either made their living off of ORM tools, or their hobby
They were using ORM tools for large scale applications
They were also very concerned with the uber-tactics of ALT.NET that I'm not necessarily concerned with (YET)
My overall question is:
For what type of project is Entity Framework currently suited?
But here are a few sub-questions that may help you get where I'm headed with that question:
Is EF better than nothing? I'm tired of doing everything by hand.
Does it come close to "solving the same problem" as LINQ to SQL? 2a. If yes, when would one be suited over the other? * found a thread on this question as I was going over questions with this tag, so nevermind *
Does it lend itself to simple 'quick and dirty' applications, such as when the bulk of your administrative CRUD forms?
edit: for those that might be curious, I am mostly working on small to medium sized applications. That can guide your response, or not.
The Entity Framework is suitable for all applications which would benefit from having an ORM layer. Daniel Simmons post goes into detail on this.
http://blogs.msdn.com/dsimmons/archive/2008/05/17/why-use-the-entity-framework.aspx
Entity Framework is similar in many ways to Linq for SQL but is not tied to MS SQL Server which Linq for SQL is. In addition EF supports more flexible mapping between your business/domain objects and the data tables. Linq for SQL supports more of a one to one mapping whereas EF supports ability to map a single object to multiple tables, or a single table to multiple objects. You do have decent designer support in both.
In the open source world, NHibernate is probably the most advanced and in many ways is the more mature product (it certainly supports a wider array of features to some regard). But with EF you get the full support of MS and the close integration into the visual studio toolset and .net framework stack. EF also as a better Linq profider than NH at the time of writing.
For a quick and dirty application i would lean towards Linq for SQL to be honest, if you can live with MS SQL Server and the mapping restrictions.
For a more complex application i would use EF or NHibernate.
You might be interested in a vote of confidence post i gave on the EF
http://blog.keithpatton.com/2008/06/24/A+Vote+Of+Confidence+For+The+Entity+Framework.aspx