Object Relational Tool Comparison Dot Net

This list for the IDEAL O/R Framework is somewhat based on a similar list in ObjectRelationalToolComparison (very similar to this list just for Java instead of DotNET.) but has a lot of .NET specific "extra-features". I am 100% sure there is no ORM .NET product that matches all this requirements, but let's see who comes closer:

Frameworks included in the comparison

Additional options to consider: Additional feature comparison proposals (at least for a VS dev environment): note: (i've been using Diamond Binding for last couple of projects - not sure if these are must-haves for an OR mapper, but they struck me as nice to have) List of Features Compared

The Visual Controversy

You may have noticed that some features ask the question "Visually?", being able to visually databind your objects to the UI is a very important feature for an O/R mapper in the .NET world (because, if a lot of users are going to want the ease of use of the DataSet when using your O/R Mapper in the development of WinUI (WindowsForms.NET) or WebUI (ASP.NET) applications. [Note: I disagree with this; while databinding support is important, it makes little sense to ask for specific ASP.NET/WinForms?/WebService support in an ORM; questions 37 and 39 could be dropped imho]

I think questions for compatibility with ASP.NET/WinForms?/WebService shouldn't be dropped, on the contrary, they should be extended, it would be great to have an O/R Mapper that makes it easier to handle object exchange between ASP.NET sessions (or object reuse between ASP.NET requests) it would also be great if someone makes an O/R mapper that could communicate with its datalayer using WebServices... so that... perhaps, different O/R frontends could communicate with a common O/R backend... Finally, think why a lot of people it is still using the DataSet... IMHO it is mainly because it is very well integrated with VisualStudio, if you want that your O/R mapper become widely used, you need to provide the same level of ease of use, raw power with out ease of use, might make your O/R Mapper very popular with code experts, but it won't make regular visual programmers use it (and there are many more regular visual programmers).


Some people think that DataBinding to the UI is orthogonal to ObjectRelationalMapping. If an object implements the interfaces from the System.ComponentModel? namespace it can be bound to a WinForms? or ASP.NET user interface. That's a separate issue from whether it can be transparently persisted to a relational database. but I disagree... take for example the need to use OpenSessionInView? with NHibernate, in that case the API makes really cumbersome to "transparently load" a previously persisted relationship because NHibernate does not support "Non-transactional lazy loading of relationships" so... ObjectRelationalMapperShouldMakeItEasyForTheUserInterfaceToFetchDataInteractively? ... or not? and... if an ObjectRelationalMapperDoesNotNeedToMakeItEasyForTheUserInterfaceToFetchDataInteractively? is it really a TransparentObjectRelationalMapper?? What is more important? To be AbleToPersistPlainOldObjects? or to make it EasyToManipulatePersistentObjects? should we go for the AnemicDomainModel? (AbleToPersistPlainOldObjects?) or the RichDomainModel? (EasyToManipulatePersistentObjects?)? Should something like the SeamFramework be built for the DotNet platform to solve this problem?-- LuxSpes


There is also the consideration of the popularity of ComponentbasedScalableLogicalArchitecture. Interoperability with CSLA (or providing a CSLA-like DataPortal?) would also be a merit for a framework that is to be used in a 3+-tier environment. Serialization is a start, but there are other issues required for a remote dataportal to know how to handle the objects.


Questions 45 & 46 added on March 26, 2005.

Details for each criteria

Other Comparisons

Fabrice Marguerie published an article on the criteria to consider when choosing an object-relational mapping tool: http://madgeek.com/Articles/ORMapping/EN/mapping.htm

How-To-Select an Object-Relational Mapping Tool for .NET: http://www.howtoselectguides.com/dotnet/ormapping/ (uncomplete and not up2date)


The sheer size of the wish-list is more evidence that one should avoid O/R mapping tools. OOP is not well-suited for business domain modelling; use it just for machine-centric abstractions. (See OopNotForDomainModeling). OO has its place, but that place is not "everywhere". -t


CategoryDotNet


EditText of this page (last edited April 10, 2014) or FindPage with title or text search