views:

147

answers:

1

Having used all of them (some more than others), I am still undecided on which could be the best to use (with .NET 3.5). What are the pro's and con's of each when developing?

SubSonic 3
Not enough samples/documentation (I know its a wiki and people can update it, but it can be tricky to track things down - e.g. where are the sample apps (WebForms, MVC (current version, rather than pre-3), WinForms)). Text Templates didn't work as expected when I first tried them. For example, it does not clean up the table names like SubSonic 2 did (removing/replacing spaces for example). Also, you cannot say which tables to include, just the ones you can exclude (in ActiveRecord.tt). Context.tt and Structs.tt generates code for all the tables (you would probably not want the 'aspnet_' ones, and probably some others (session tables) as well).

Saying that though (hope I'm not being too harsh), it is quite a good ORM to use, minor issues aside.

Entity Data Model (Entity Framework)
Visual Designer for setting up models. Syncs with database, might be considered a bit 'verbose' and hard to understand. There is fairly decent documentation though. Not gone that much further in depth though.

LINQ to SQL Also has a designer for creating models. Simple to use. Less features than the other two. I also had to apply a hotfix for an obscure bug (wouldn't update when the model had foreign keys that were not of type int)

NHibernate
Looked at this in the past, but not that easy to set up compared to the above. Any sample ASP.NET MVC apps using this?

Ideally I would want a framework that:

a) could generate the models from a database
b) support LINQ syntax
c) retrieve only the data that is needed (e.g. for paging)
d) allow data annotations
e) could generate the sql to update or create new tables in an existing database

+1  A: 

MVC is presentation layer, ORM is Data layer

I don't think that ORM has anything so much to do with an MVC application. At least if you tier your application properly. Model in an MVC application is rather model of the presentation layer view. A view model through which controller and view communicate. Not necessarily data model. MVC project template is a bit confusing, since developers think that MVC model = data model. In any business application that is not completely trivial (like a single assembly simple application) this is not equal. And it's better that its not. Especially if we take into cosideration separation of concerns. We shouldn't rely on particular ORM classes in any layer other than data layer.

But if you intend to use DTOs in your MVC application (as view models) I suggest you use that ORM that creates partial classes, so you can easily add additional stuff on them (like attributes). Your data annotations can be written inside of a special metadata class that can be attached to your model class by a single class-level attribute.

Suggestion

But I suggest doing something else. Use a separate layer with POCOs that will be used on all layers and would have data annotations on them. This will make your presentation layer independent of data layer and your POCOs may also be presentation optimised (like having a class called UserRegistration for instance with two password properties - with repeated value as well). Your repository in your data layer would be responsible for POCO conversion so all layers will exchange data using POCOs only instead of using data objects.

ORMs and class generation

With Entity Framework you do get a very controllable environment to generate your classes from a data store schema. Unfortunately it's not the same with others. Generateion is not all-in, but can be controlled and manipulated manually as well (if you'd like to do TPH/TPT structures).

Similar with LINQ to SQL. I haven't used any other ORM but I guess LinqConnect may have it's own editor similar to EF Visual Studio editor, because I've been working with MySql connector from the same company and I've used their designer for entities because it was better than the one provided with Visual Studio 2008.

But you have tools that provide code generation (and you can get templates on the internet for various ORMs as well):

  • there's T4 built into Visual Studio that can generate code for you; You can as well fint templates for ORMs written in T4 that you can then easily customize. Or write your own acording to your needs (I've written enumeration generator from DB lookup tables in the past)
  • MyGeneration is open source and you can find lots of templates for it
  • CodeSmith is not free but is a proved product that I've used in the past with .netTiers template (before we had LINQ) which saved lots of time and worked perfectly
Robert Koritnik
Isn't MVC 3 layers (Model = data layer, View = presentation, Controller = business logic)? So ORM can be part of it?
Sam
@Sam: Not exactly this way, but in simple projects Model (in MVC) = DTOs (ORM classes). I rather think of model in MVC as a ViewModel, because if we look at MVC framework Controller does business logic, View does present data to the user and interacts with it, but **model** is normally used for communication between these two. Data model on the other hand is an outside part that may be accessed by controllers to get data to populate MVC models. As said. These may be the same classes, but MVC doesn't imply they should be. And I think they shouldn't be.
Robert Koritnik
I use MyGeneration and some projects I have developed are still using dOOdads now (also uploaded 30+ templates to the template library).
Sam
People could interpret an ORM as a model though, since the Entity Framework is used in the MVC music store tutorial and the generated classes are stored in the Models folder. NHibernate (and perhaps Entity Framework as well) could be considered overkill for simple projects, but Entity Framework is far quicker and easier to set up.
Sam
@Sam: MVC project template is meant to be developed as a single assembly application. Most of the time this is not the case and it does confuse developers so they think that M (as model) actually stands for data model. I usually have custom POCOs for M and all layers communicate using these. But they don't reside in MVC/Model folder, but are rather part of a separate project so all assemblies reference these classes. Repositories use EF data model and create POCOs and pass them to service layer.
Robert Koritnik
Not seen any examples of doing it like that (though that would make the tutorial longer). Not got much experience with MVC (have been using ASP.NET for a while though), just based on the tutorials on the asp.net mvc site.
Sam