0

I have been working on my first experimental DDD project. The objective of this project is for me to get a feeling on the whole DDD concept. Oddly enough, as i have read it's the more difficult part, i find the ubiquitous language "translation" easier than the whole architecture itself, thus my question.

I have only used in my past projects L2S (Linq to SQL). My applications were not DDD per se but they do have a Business Object (aside from the ones that linq to sql generates) and i have a repository for this objects. For example,

public class Customer
    {
       public ID {get; set;}
       public string Fullname {get; set;}
       public Address address {get; set;}
       public List<Invoices> invoices {get; set;}
    }

Now, in L2S, i have to breakdown this class into three different queries and submit them into the database. I have a mapper (extension methods) to make my life "easier". Something like this.

public void AddCustomer(Customer customer)
{
// This customer i am passing is the business object
// For the sake of demo, i am going to avoid the whole attach(), check for ID, etc.
// I think you are going to get what i am trying to do here.

using{ var context = new L2SContext())
{
context.CustomerEntity.InsertOnSubmit(customer.ToEntity());
context.AddressEntity.InsertOnSubmit(customer.Address.ToEntity());
context.InvoicesEntity.InsertAllOnSubmit(customer.Invoices.ToEntity());
}
}

Ok. Later on i have a SubmitChanges() method in the context where i actually persist the data to the database.

Now, i don't know much, almost anything, about NHibernate. But looking at some examples, i am suspecting that NHibernate takes care of all that breakdown for you (because of the mapping?) so you only have to pass Customer and it will do the rest. Is that Correct?

I am willing to learn NHibernate if I really see a HUGE benefit from it.

Thank you for checking out my question.

EDIT: Have you heard of Codesmithtools.com? They have a framework generator for LinqToSql, EF, NHibernate. Has anyone tried their NHibernate? I have used PLINQO for LinqToSql but they add so much crap to the classes that i believe are unnecessary. Pretty much the classes are suit to be used, for bad programmers, as business classes, DTO, ViewModels, etc. All In One :). Terrible. BUT, they are really good at generating all that. i have to give them KUDOS for that.

Pepito Fernandez
  • 2,352
  • 6
  • 32
  • 47
  • 3
    Yes, you would just save the customer and NHibernate can then see what invoices and other entities have been changed and will save those for you as well. There is a steep learning curve to get things working when you're not familiar with NHibernate, but after that it is pretty rewarding. – Jack Hughes Nov 13 '12 at 15:50
  • Thank you Jack. I am looking into some tutorials. I am getting confused about fluent nhibernate and nhibernate, also nhibernate MBC? which is the one i need in your opinion? – Pepito Fernandez Nov 13 '12 at 17:47
  • I use just plain old NHibernate myself. Found that Fluent NHibernate was very very nice but the service I was developing was failing because fluent NHibernate was taking so long to create the configuration. That was a couple years ago, I'm sure things have changed since then. Not heard of NHibernate MBC so can't comment on that. I'd start with fluent NHIbernate if I were starting a green field project now I think. Not hard to migrate to plain NHibernate XML configs if necessary. – Jack Hughes Nov 14 '12 at 08:48
  • If you want to understand DDD, don't use a database. Use something in memory if you really have to. If the app is properly designed, then adding a real db should be very easy. Don't make the mistake to consider Nhibernate entities as domain entities. http://www.sapiensworks.com/blog/post/2012/04/20/Dont-Use-ORM-Entities-To-Model-The-Domain.aspx. Btw, IMO there are no HUGE benefits in using an ORM everywhere. A micro Orm does all the things you really want and it's MUCH easier to learn – MikeSW Nov 14 '12 at 09:55
  • Also note that DDD entities typically do not have public setters. You take actions on entities by invoking methods. The entity should be responsible of updating it's information, not the caller. – jgauffin Nov 15 '12 at 09:26

2 Answers2

1

A few points for NHibernate over Linq-2-SQL for DDD:

  • Persistence by reachability. This can also be called cascading saves, but it would allow you to persist the customer entity without having to explicitly insert them. This fits nicely with DDD because Customer would be an aggregate and Address would be a value object. In NHibernate, value objects are represented as component mappings and entities and aggregates as class mappings. Aggregates should be persisted and retrieved as single units and NHibernate allows you to do this.

  • Persistence ignorance. NHibernate allows you to design your classes as pure POCOs, without references to additional libraries. As far as I remember, L2S required a special type for collections, as well as requiring explicit foreign keys as properties. Note, that even with NHibernate persistence ignorance is an ideal, not a goal.

As pointed out by others, there is a steep learning curve to NHibernate. For example, lazy loading can be problematic. But it is worth it overall.

eulerfx
  • 36,769
  • 7
  • 61
  • 83
0

Your question is open-ended. It is obvious that you now how Linq-2-SQL works. As the first comment already said: yes NHibernate can provide cascading saves. But this is only the beginning... Please, first of all, check this question and answers (there are more than one interesting):

NHibernate vs LINQ to SQL

I am using NHibernate on my private projects as the first choice. If possible I prefer it on any project. But, I would like to append one more NOTE, from my experinece:

The biggest benefit is, that once you will learn and work with NHibernate, it won't be so much difficult to work with other ORM tool. On some projects you will (I did) meet Entity Framework on some LLBL Generator..., and (while we can blame that something in comparsion with NHibernate is missing;) we can quickly:

  • understand the domain, because ORM forces the Entity/Domain driven implementation
  • use standard patterns

Wish it helps and good luck with NHibernate. Learning curve is maybe slower then expected, but benefits await.

Community
  • 1
  • 1
Radim Köhler
  • 122,561
  • 47
  • 239
  • 335
  • Thank you Radim. I had already read that article. Now the question is, after reading about Fluent NHibernate, NHibernate MBC... which is which? Or, which one is the best one. Since it's an open source, i guess there are multiple variants out there. – Pepito Fernandez Nov 13 '12 at 17:46
  • Yeah ;) this is a nice question. I tried to use the default distribution as much as possible. E.g. XML mapping, Criteria language, powerful QueryOver. For custom needs we used extension points (and there are many like event listeners). But I never found useful to use plugins like fluent mapping, LINQ provider... because all of these were built on top of NHibernate, trying hide some difficulties of NHibernate - but hard to say if that was fulfilled. So I personally would suggest start with the defaults. – Radim Köhler Nov 13 '12 at 18:39
  • @Tony see http://stackoverflow.com/a/8294639/671619 for some facts about FluentNH vs MBC – Firo Nov 14 '12 at 13:30
  • @Firo, briliant topic! Good reading, many facts. My favourite after playing with fluent is still xml. But it is definitely personal – Radim Köhler Nov 14 '12 at 13:46