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.
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.
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.
Related
What is the right way to create DTOs from business objects?
Who should be responsible for creating them? BO/DTO itself from BO/some static factory?
Where should they reside in code if I have, f.e. some core library and a specific service API library that I need DTO for? In core library next to BO(which seems incorrect)/in specific library?
If I have encapsulated fields in my BO how do DTO grab them? (obviously in case when BO is not responsible for creating DTOs)
As an example assume that I have some Person BO like this:
class Person
{
private int age;
public bool isBigEnough => age > 10;
}
I want age to be an internal state of Person but still I need to communicate my BO to some api. Or having private field in my class that I want to send somewhere already means that it should be public?
Are there any general considerations of how to use DTOs alongside business classes with encapsulated data?
___ Update:
In addition to approaches that #Alexey Groshev mentioned I came accross another one: we separate data of our BO class into some Data class with public accessors. BO wraps this data with its api(probably using composition) and when needed it can return its state as Data class as clone. So dto converter will be able to access Domain object's state but won't be able to modify it(since it will be just a copy).
There're multiple options available, but it would be difficult to recommend anything, because I don't know the details about your project/product. Anyway I'll name a few.
You can use AutoMapper to map BOs to DTOs and vise versa. I personally dislike this approach, because it's quite difficult (but possible) to keep it under control in medium/large sized projects. People don't usually bother to configure mappings properly and just expose internal state of their objects. For example, your isBigEnough would disappear and age would become public. Another potential risk is that people can map DTOs to/from EF/Hibernate objects. You can find some articles which explain why it's considered to be a bad practice.
As you suggested, a BO can create DTO by itself, but how would you implement this approach? You can add methods or factory methods to your entities, e.g. public PersonDto ToDto(). Or you can add an interface, e.g. public interface IDtoConvertable<T> { T ToDto(); }, and choose which entity or aggregate root will implement it. Your Person class would look like this class Person : IDtoConvertable<PersonDto> {... public PersonDto ToDto() {...} }. In both cases DTO namespace/assembly must to accessible by entities which sometimes can be a problem, but usually it's not a biggie. (Make sure that DTOs cannot access entities which is much worse.)
(C#) Another option is to return a delegate which creates DTO. I decided to separate it from (2), because entity doesn't really create DTO by itself, but rather exposes a functionality which creates DTO. So, you could have something like this public Func<PersonDto> ToDto() {...}. You might want to have an interface as in (2), but you get the idea, don't you? Do I like this approach? No, because it makes code unreadable.
As you see, there are more questions than answers. I'd recommend you to make a few experiments and check what works for you (your project) and what doesn't.
I think the answer to question 5 will address the other questions too.
Are there any general considerations of how to use DTOs alongside business classes with encapsulated data?
Remember, a DTO is solely to transfer data. Do not concern yourself with implementing any kind of rules in the DTO. All it is used for is to move data from one subsystem to another (NOT between classes of the same subsystem). How that data is used in the destination system is out of your control -- although as the God programmer you inherently know how it is going to be used, DO NOT let that knowledge influence your design -- and therefore there should be no assumptions expressed as behaviour or knowledge accessors -- so, no isBigEnough.
I have a chance to introduce NHibernate to my group by using it with some new components that are being added to a legacy application. I'm trying to get my head around using the DAO pattern with NHibernate, and am stumped with an architectural question.
In my fictional example, let's say I have CarDAO and a Car entity:
public interface CarDAO {
Car FindById(int id)
... // everything else
}
public interface Car {
... various properties and methods
}
I have a need to be able to convert a car to right-hand drive. Since this would be a very complex operation, I need to execute a stored procedure. I'm not clear on where the ConvertToRightHandDrive() method should go.
It makes sense to me to put the method on Car, and let it call a method on the CarDAO that will execute the stored procedure. And this is where I'm not clear:
should Car have a reference to the CarDAO and call CarDAO.ConvertToRightHandDrive?
should there be some sort of CarService layer that calls CarDAO.ConvertToRightHandDrive?
what about injecting the CarDAO through the method on Car (Car.ConvertToRightHandDrive(carDAO))
some other option?
Perhaps this is only a religious argument, and people have differing opinions on whether or not an Entity should have a reference to its DAO (or any other DAO, for that matter). I've been searching StackOverflow for some time, and have seen several discussions around this topic; but, I'd be interested in people's opinions in this particular scenario.
The way I was always told to think about it is that Entities should have as little in them as possible and that various objects should perform operations against entities. The entities themselves should not be aware of the DAL or they lose their data storage ignorance
So in this case, a CarManager (or similar) which possibly has a dependency on the CarDAO should have a ChangeToRightHandDrive(Car) method.
Oh and one other advantage to having a CarManager which performs the complex operations is that you're not relying on stored procs - This is almost certainly a religious issue but I prefer to have all the logic in my code rather than relying on SPs (There are a few exceptions but usually only around large sets). This means that if you changed to another DAL (say XML), you wouldn't need to re-implement your SP in your DAL/DAO - Otherwise, you'd end up with business logic embedded in your DAL.
My opinion is that Car should have no knowledge of CarDAO. This keeps your domain model clean and allows you to change your back-end without affecting the Car class.
If you need to call a stored procedure to convert a car to right-hand drive, I like the option of having a CarDAO.ConvertToRightHandDrive(Car car) method and then using something like a CarService class to hide the dependency on CarDAO from any callers (i.e. the CarService class would have an identical method that would just forward the call to CarDAO).
As you mention, people will definitely disagree on this type of thing, but it's always worth carefully considering dependencies and coupling before you start hacking away.
Hi Im curious about how DDD is really implemented using Fluent Nhibernate. for example I have an entity class called User and another class called UserProfile, as far as Im concerned UserProfile is not an entity class but a value type, and should not realy have an identity as such if not associated with a User entity. Now to implement practically the user profile will ideally be stored in a database table called UserProfile and I cant see how I can get away from having a unique Id for this table. I am also using FluentNhibernate as an ORM and I beleive THE UserProfile class needs to have an Id in order to be mapped correctly. So what happens to the concept of values types, aggregate root etc, Is it really possible to implement a true DDD with fluent Nhibernate or is it just that my understanding of DDD is poor. All I have really seen is a lot of theory about the whole thing, but I have not seen a project that really has true DDD using NHibernate. I am a bit confused now, any help is appreciated
Update
Okay after a bit of reading up I understand that repositores are used to manage Aggregate roots, clears up some of the issues but ultimately the userprofile class is not an aggregare root, so should I still give it a Id? it obviously needs one in the database table so Im assuming the class needs an Id as well. But does this not go against the principle of DDD? what is the way around this?
It will need an Id to be supported by your ORM (NHibernate), and that's perfectly fine. The distinction between Entities and Value Types is their concepts of identity and lifetime. Having an Id field is simply an implementation detail here.
I think I am at a impasse here. I have an application I built from scratch using FluentNHibernate (ORM) / SQLite (file db). I have decided to implement the Unit of Work and Repository Design pattern. I am at a point where I need to think about the end game, which will start as a WPF windows app (using MVVM) and eventually implement web services / ASP.Net as UI.
Now I already created domain objects (entities) for ORM. And now I don't know how should I use it outside of ORM. Questions about it include:
Should I use ORM entity objects directly as models in MVVM? If yes, do I put business logic (such as certain values must be positive and be greater than another Property) in those entity objects? It is certainly the simpler approach, and one I am leaning right now. However, will there be gotchas that would trash this plan?
If the answer above is no, do I then create a new set of classes to implement business logic and use those as Models in MVVM? How would I deal with the transition between model objects and entity objects? I guess a type converter implementation would work well here.
To answer the first part of your question, yes your business logic and validation should go in your entities. The point of NHibernate is to let you design your entities to be persistence ignorant. That means that you should, whenever possible, be designing your entities as you would if you didn't care about persistence. This isn't entirely feasible as you'll soon find out (you'll need to make your properties virtual in order to support lazy loading and if you want to use NHibernate Validator you'll be decorating your properties with validation attributes), but for the most part NHibernate does a good job of staying out of your way.
As for whether to use your entities as the models, you'll get mixed reviews on that. Ideally, you would create separate viewmodel classes and map from your entities to the viewmodel so that your views will only access to the bare minimum of information they need. This also goes a long way in preventing N+1 access issues. However, doing so is often a huge pain. Granted, there are tools like AutoMapper that will make it easier from transposing your entity properties to a viewmodel.
I dig a lot of things about the DDD approach (Ubiquitous language, Aggregates, Repositories, etc.) and I think that, contrary to what I read a lot, entities should have behavior rather then being agnostic. All examples I see tend to present entities with virtual automatic properties and an empty constructor (protected or worst, public) and that's it. I consider this kind of objects more like DTOs then entities.
I'm in the process of creating a framework with its specific API and I don't want to be tied to an ORM. So I built the domain first (without thinking of persistence) and now I would like to use NHibernate as persistence tool so I added a new project to my current solution to help ensure that my model isn't altered to support NHibernate. This project should be an implementation of the abstract repositories that live inside my domain. And now the difficulties arise.
Since it is my first time with NHibernate (I'm also trying Fluent Nhibernate but it seems even more restricting) I would like to know :
Is it possible to use NHibernate without altering a DDD model that is part of a framework
The things (constraints) that are necessary for NHibernate to work as expected and efficiently (virtual properties, empty constructors, etc.) I think this list would be helpful to a lot of people who are starting to learn NHibernate.
Please keep in mind that I'm building a framework so the Open/Closed Principle is very important for me.
P.S.: Sorry if my english is not good, I'm from Montreal and I speak french.
Edit 1: Here is one problem I have with NHibernate now - How to map Type with Nhibernate (and Fluent NHibernate)
For NHibernate:
All mapped classes require a default (no-arguments) constructor. The default constructor does not have to be public (it can be private so that it is not a part of the API), but it must exist. This is because NHibernate must be able to create an instance of the mapped class without passing any arguments. (There are workarounds, but don't do that.)
All mapped properties for which lazy-loading will be required must be marked virtual. This includes all reference properties and all collection properties. This is because NHibernate must be able to generate a proxy class deriving the mapped class and overriding the mapped property.
All mapped collection properties should use an interface as the property type. For example, use IList<T> rather than List<T>. This is because the collections types in the .NET Framework tend to be sealed, and NHibernate must be able to replace a default instance of the collection type with its own instance of the collection type, and NHibernate has its own internal implementations of the collection types.
For NHibernate, prefer Iesi.Collections.Generic.ISet<T> to System.Collections.Generic.IList<T>, unless you are sure that what you want is actually a list rather than a set. This requires being conversant in the theoretical definitions of list and set and in what your domain model requires. Use a list when you know that the elements must be in some specific order.
Also note that it's typically not easy to swap object-relational mapping frameworks, and in many cases it is impossible, when you have anything beyond a trivial domain model.
The short answer to your question is that it is not possible, but if don't need lazy loading the required alterations are trivial.
No matter what, you will have add default constructors to classes that do not already have them. If you are willing to forgo lazy-loading, those default constructors can be private, and you don't have to make any other changes to your domain model to use NHibernate.
That's awfully close to persistence ignorance.
Having said that, if you want lazy-loading, you'll need to make several changes (outlined in other answers to this question) so that NHibernate can create proxies of your aggregated entities. I'm personally still trying to decide whether lazy-loading is an enabling technology for DDD or if it's a premature optimization that requires too many intrusive changes to my POCOs. I'm leaning toward the former, though I really wish NHibernate could be configured to use a specific constructors.
You might also take a look at Davy Brion's blog (I particularly liked Implementing A Value Object With NHibernate), which is really illuminating if you're interested in domain-driven-design and avoiding anemic domain models.
In my experience, the only thing that NHibernate requires of a domain is virtual properties and methods and a default no-argument constructor, which as Jeff mentioned, can be marked private or protected if need be. That's it. NHibernate is my OR/M of choice, and I find the entire NHibernate stack (NHibernate, NHibernate Validator, Fluent NHibernate, LINQ to NHibernate) to be the most compelling framework for persisting POCO domains.
A few things you can do with NHibernate:
Decorate your domain model with NHV attributes. These constaints allow you to do three things: validate your objects, ensure that invalid entities are not persisted via NHibernate, and help autogenerate your schema when using using NHibernate's SchemaExport or SchemaUpdate tools.
Map your domain model to your persistent storage using Fluent NHibernate. The main advantage, for me, in using FNH is the ability to auto map your entities based on conventions that you set. Additonally, you can override these automappings where necessary, manually write class maps to take full control of the mappings, and use the xml hbm files if you need to.
Once you buy into using NH, you can easily use the SchemaExport or SchemaUpdate tools to create and execute DDL against your database, allowing you to automatically migrate domain changes to your database when initilizing the NH session factory. This allows you to forget about the database, for all intents and purposes, and concentrate instead on your domain. Note, this may not be useful or ideal in many circumstances, but for quick, local development of domain-centric apps, I find it convenient.
Additionally, I like using generic repositories to handle CRUD scenarios. For example, I usually have an IRepository that defines methods for getting all entites as an IQueryable, a single entity by id, for saving an entity, and for deleting an entity. For anything else, NH offers a rich set of querying mechanisms -- you can use LINQ to NHibernate, HQL, Criteria queries, and straight SQL if need be.
Th only compromise you have to make is using NHV attributes in your domain. This is not a deal breaker for me, since NHV is a stand-alone framework which adds additional capabilities if you choose to use NHibernate.
I have built a few apps using NH, and each has a persistence ignorant domain with all persistence concerns separated into its own assembly. That means one assembly for your domain, and another for your fluent mappings, session management, and validation integration. It's very nice and clean and does the job well.
By the way: your English is pretty darn good, I wish my French was up to par ;-).
Just to put my two bits in, I struggled with the same thing once but I overcame this by:
Adding protected default constructor to every entity.
Making Id virtual
Let's take for example upvote and downvote for Vote entity on my experiment website:
http://chucknorrisfacts.co.uk/ (NHibernate + MySQL with Mono)
public class Vote : Entity
{
private User _user;
private Fact _fact;
// true: upvote, false: downvote
private bool _isupvoted;
// for nHibernate
protected Vote() { }
public Vote(User user, Fact fact, bool is_upvoted)
{
Validator.NotNull(user, "user is required.");
Validator.NotNull(fact, "fact is required.");
_fact= fact;
_user = user;
_isupvoted = is_upvoted;
}
public User User
{
get { return _user; }
}
public Fact Fact
{
get { return _fact; }
}
public bool Isupvoted
{
get { return _isupvoted; }
}
}
This class inherits from Entity where we stick all the minimum necessary for Nhibernate.
public abstract class Entity
{
protected int _id;
public virtual int Id { get {return _id;} }
}
and Fluent mapping where you Reveal the private property.
public class VoteMap : ClassMap<Vote>
{
public VoteMap()
{
DynamicUpdate();
Table("vote");
Id(x => x.Id).Column("id");
Map(Reveal.Member<Vote>("_isupvoted")).Column("vote_up_down");
References(x => x.Fact).Column("fact_id").Not.Nullable();
References(x => x.User).Column("user_id").Not.Nullable();
}
}
You could probably place protected default constructor in Entity class and configure nHibernate to use it instead but I didn't look into it yet.