You are currently viewing the BOOK: .NET Domain-Driven Design with C#: Problem - Design - Solution ISBN: 978-0-470-14756-6 section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developersí questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
Great book. I'm only through the first 2 chapters so far, but have a hard time putting it down. I look forward to downloading the application and learning from it.
I had a question about why you chose the Enterprise Library for persistence. I have nothing against it, but I'm just tend to be on the lazy side, and like using an ORM just because it saves so much time. I particularly like LLBLGen at this point, though I'm starting to learn nHibernate. I'm thinking it should be pretty easy to plug an ORM into your framework, and I just wanted to pass the thought by you to see if you agree.
as already said in all previous post - my congratulations for this great book!
great to see the tdd/domain model in a "real world" sample.
funny sidenote - we are currenty porting an access application to .net 3.5. :)
In my current application i want to use many of your ideas (and the ideas form jimmy nielson, e.evans, ...).It would be realy interesting to see nHibernate (which i want to user in my application for persistence) in combination with your Domain Model/repository/service design.
Some things i am not sure about how to implement is the combination of f.e. "unit of work", "lazy loading", "entity map", from your domain model with the same concepts of nHibernate.
nHibernate already supports "unit of work", "lazy loading" a.s.o.
So should i rely for this functions on nHibernate? (which i think i not so good, because nHibernate is in the persistence layer).
On the other hand - should i RE-implement this concepts in the domain model (as you did). I thik, you had to do it, because you implemented the persistence layer by yourself but what would be the best practice, if you have a framework (nHibernate), that already offers these functionality?
Another really great idea (i also want to support) ist LINQ.
LINQ to "myReposotiry" - i thing, this would be a gread implementation of the "query pattern" + i would love to see it in action in your domain model.
Maybe you find time for this in a next release of your book. :)
The project is written following a Domain Driven Design and has a similar architecture to Tims project and includes the Unit of Work Pattern, Lazy Loading with Repositories and a Service layer. You can download the code for free, its written in VB.net but you shouldn't find it hard to convert to C#.