We Keep Coding

How is Change Tracking an issue when separating the Domain Model and Persistence Model?

I was reading this question here: Having Separate Domain Model and Persistence Model in DDD
and specifically looking at this code:
public class ApplicationService
{
private ITicketsRepository ticketsRepository;
public ApplicationService(ITicketsRepository ticketsRepository)
{
this.ticketsRepository = ticketsRepository;
}
public bool IsTicketExpired(int ticketId)
{
Ticket persistanceModel = this.ticketsRepository.GetById(ticketId);
TicketEntity domainModel = new TicketEntity(
persistanceModel.Id,
persistanceModel.Cost,
persistanceModel.ExpiryDate);
return domainModel.IsTicketExpired();
}
}
This code means there is a separate Domain Model and Persistence Model. I am trying to understand what the limitations of using this approach are. All over the Internet I read about change tracking being an issue when using NHibernate, however I do not understand why. Change Tracking is dealt with after the domain model is mapped back to the persistence model. How is change tracking an issue? A practical example of how change tracking is an issue would help me.
Update
Please see the code below:
//Repository
public Ticket GetTicket(int ticketId)
{
return this.ticketsRepository.GetById(ticketId);
}
and I do this in the application service:
//Application Service
Ticket ticket = applicationService.GetTicket(1);
ticket.Cost = .....
TicketEntity ticketEntity = AutoMapper.Map<TicketEntity>(ticket);
ticketEntity.DomainMethod();
ticket = AutoMapper.Map<Ticket>(ticketEntity);
Q1) Are the benefits of an ORM lost in this code e.g. change tracking? Notice that the persistence object is returned from the repository and then is mapped to a domain object and then back to the same persistence object.
Q2) How does NHibernate track changes i.e. how does it know that Ticket(persistence object) is ticket 1 in the database. I guess it is not simply by the ID.

Change tracking is no issue. The mingling of Domain with Persistence is. The 'domain model' is mainly some data structure easily mapped to a table. In many domains, you might deal 99% with data structures with some rules attached. In those cases, your Domain model will look pretty much identical to Persistence model.
But going up a bit, at a more abstract level, the Domain Model models primarily business behaviour with state (data) being just an artifact. Further more, it looks at things from the business point of view (functionality).
Persistence model is about stored state i.e data structured in such a way that's easily retrievable. For domains with complex functionality that involves many concepts and their specific models and use case specific business rules, the resulted Model is quite different from the Persisted state.
How an ORM tracks changes is just an implementation detail that has nothing to do with DDD, however if the domain is rich enough, the simplistic CRUD solution and especially the mindset of domain model = state+behaviour a.k.a classes becomes an obstacle. With or without the ORM.
For the apps where the Domain = 98% Persistence Models, there's no problem, you can use whatever ORM you want.

Most of the details in answer from #MikeSW are correct; I only disagree with change tracking. My answer is more in terms of NHibernate than DDD.
Yes, change tracking will be an issue but it depends on how the ISession is managed. Further, not only change tracking, it will also affect other features of NHibernate like Session Level Cache, Lazy Loading etc.
Let us assume that ISession is managed on request level i.e. one ISession per request. And all activities mentioned below are part of one single request.
public TicketEntity GetTicket(int ticketId)
{
Ticket persistanceModel = this.ticketsRepository.GetById(ticketId);
TicketEntity domainModel = new TicketEntity(
persistanceModel.Id,
persistanceModel.Cost,
persistanceModel.ExpiryDate);
return domainModel;
}
public void SaveTicket(TicketEntity ticketEntity)
{
Ticket ticket = //Here, you have to map TicketEntity to Ticket
this.ticketsRepository.Save(ticket);
}
Now, following is the code somewhere in application in same request:
TicketEntity ticketEntity = applicationService.GetTicket(1);
ticketEntity.Cost = .....
.....
.....
applicationService.SaveTicket(ticketEntity);
NHibernate have ability to track changes happen in Ticket but that ability is not useful here. Ticket is lost while returning from GetTicket and new Ticket is created while SaveTicket. Change tracking feature of NHibernate is not used at all even though ISession was at request level and was able to see the changes happen.
Following code (which bypasses domain models) will track the changes properly though:
public Ticket GetTicket(int ticketId)
{
return this.ticketsRepository.GetById(ticketId);
}
Following is how you get and modify Ticket:
Ticket ticket = applicationService.GetTicket(1);
ticket.Cost = .....
.....
.....
Now, you do not call SaveTicket; instead you Flush the ISession somewhere in your application where you detect the EndOfRequest.
In this scenario, change tracking of NHibernate tracks the changes done to Ticket and flushes those automatically.
By translating persistence model to domain model, we bypass this ability of NHibernate because persistence model is never changed.
There are benefits and drawbacks of each approach. Refer this question.
Edit: (for your Update)
Q1): New code will take benefit of change tracking if same instance of persistence model is modified and visible to same ISession. It will also take benefit of Session Level Cache in that case. While mapping with AutoMapper, NHibernate will load referenced entities if any those may not be needed. This depends on each use-case though.
Q2): Actually this should be a different question being too broad to answer in this answer. Anyway, refer this.

On a side note, I would not recommand to separate domain model classes from persistence objects.
You might want to see what Vaughn Vernon did for his application on DOT.NET
He is the author of the famous book Implementing Domain Driven Design (IDDD). A must read that I recommand to any developer serious about DDD.
https://github.com/VaughnVernon/IDDD_Samples_NET/tree/master/iddd_identityaccess/Domain.Model/Identity

DTO vs. Domain Model, project organization

I have a project with a repository, a service layer, using EF6 and code-first POCOs. In the CustomerRepository, I am doing several projection queries that return objects.
I understand that the code-first POCO's are what would be considered "Domain Models", but if I were to do a projection query into a different model, what is that model considered? An example of this would be the CustomerOrderStats. Is that still a Domain Model, or should that be considered a DTO model?
Example
Object returned from Repository:
public class CustomerOrderStats
{
public string Name { get; set; }
public int Count { get; set; }
}
Query in the Repository
public CustomerOrderStats GetCustomerOrderStats(Guid customerGuid)
{
return customers
.Where(c => c.Guid == customerGuid)
.Select(new CustomerOrderStats
{
Name = c.Name,
Count = c.Orders.Count()
};
}

It could be either one, really. The definition of a model vs. a DTO isn't really a matter of how you organize any given framework, but rather what that object represents in the domain. If it has rich functionality or business logic or is an active part of the actual business process, it's probably a model. If, on the other hand, it's just a container of properties to move values from one place to another, it's probably a DTO.
The key here is whether the object is an active part of the business process. And a good rule of thumb here is often the name of the object.
Is it a name that non-technical business team members understand?
Is it a term they use to describe what the business does? (Even a very small part of the business)
Does it carry a meaning in the industry in general?
A DTO is generally something that exists for purely technical reasons. Component A needs to send data to Component B, but that operation is a technical one and not a business one. Data just needs to be, well, transferred. As a piece of the system, it's essentially built "from the bottom up" because it satisfies a low-level technical need.
A model describes a part of the business. It could be an element on a chart which defines the business process in non-technical terms, or an encapsulation of a business concept. As a piece of the system, it's essentially built "from the top down" because it is described generally by the business and then implemented specifically to meet that need.

Business logic integrated into entity framework

I've read some of the articles on BL, but the methodology seems counter intuitive to me. It seems to break up normal OOP principles. Here's an very simplified example: A client table contains the birthdate and gender of each client. A life expectancy table contains the clientId, age, and probability of survivorship to that age.
Wouldn't basic OOP principles call for methods to be integrated into the entity? E.g. the calculateSPTable() method in the client class.
class client {
int clientId;
int age;
bool male;
list<surviveProb> lifeExpectancy;
void calculateLifeExpectancy(); // calculates lifeExpectancy
}
class surviveProb {
int surviveProbId;
int clientId;
int age;
double probability;
}
Yet the methodologies today seem to suggest such operations must be in a separate layer and a separate class. Methods operating on entities should not be included in the entity framework entities. This seems counter intuitive. I really want to put methods into EF entities. Is this going to lead to problems? What am I missing here?

After some research I now use some patterns that I think are good for maintenance porpoises and understanding the application.
Let's say you want to register an account.
In the controller, I would have an AddAccountViewModel that only exposes the minimum properties to a user. No worries about him injecting something bad in an unexpected property. Now, using dependency injection, I would call a Facade. Let's say _accountsFacade.RegisterAccount and I would pass the View Model as a parameter.
Inside this method in the facade, I would do the mapping from the View Model to the Model and this Facade would be responsible for doing everything that needed to be done so the account could be created. In my opinion, here is where all the business logic goes. In this Facade, using dependency injection again, I use a unit of Work and add and edit entities to the context. _unitOfWork.AccountRepository.Add(account)
You see? Controllers only "route" the application, facades handle business, unit of work handles the context, the repository only communicates with the data base... And the model only expose properties.
This makes the mapping faster, as stated, and it separate concerns. Sometimes, the logic of adding an account may involve handling different objects that shouldn't be used inside the account object,
I hope you can understand what I want to explain, as my English is not so great.
Was it helpful?

Entity Framework classes vs. POCO

I have a general difference of opinion on an architectural design and even though stackoverflow should not be used to ask for opinions I would like to ask for pros and cons of both approaches that I will describe below:
Details:
- C# application
- SQL Server database
- Using Entity Framework
- And we need to decide what objects we are going to use to store our information and use all throughout the application
Scenario 1:
We will use the Entity Framework entities to pass all around through our application, for example the object should be used to store all information, we pass it around to the BL and eventually our WepApi will take this entity and return the value. No DTOs nor POCOs.
If the database schema changes, we update the entity and modify in all classes where it is used.
Scenario 2:
We create an intermediate class - call it a DTO or call it a POCO - to hold all information that is required by the application. There is an intermediate step of taking the information stored in the entity and populated into the POCO but we keep all EF code within the data access and not across all layers.
What are the pros and cons of each one?

I would use intermediate classes, i.e. POCO instead of EF entities.
The only advantage I see to directly use EF entities is that it's less code to write...
Advantages to use POCO instead:
You only expose the data your application actually needs
Basically, say you have some GetUsers business method. If you just want the list of users to populate a grid (i.e. you need their ID, name, first name for example), you could just write something like that:
public IEnumerable<SimpleUser> GetUsers()
{
return this.DbContext
.Users
.Select(z => new SimpleUser
{
ID = z.ID,
Name = z.Name,
FirstName = z.FirstName
})
.ToList();
}
It is crystal clear what your method actually returns.
Now imagine instead, it returned a full User entity with all the navigation properties and internal stuff you do not want to expose (such as the Password field)...
It really simplify the job of the person that consumes your services
It's even more obvious for Create like business methods. You certainly don't want to use a User entity as parameter, it would be awfully complicated for the consumers of your service to know what properties are actually required...
Imagine the following entity:
public class User
{
public long ID { get; set; }
public string Name { get; set; }
public string FirstName { get; set; }
public string Password { get; set; }
public bool IsDeleted { get; set; }
public bool IsActive { get; set; }
public virtual ICollection<Profile> Profiles { get; set; }
public virtual ICollection<UserEvent> Events { get; set; }
}
Which properties are required for you to consume the void Create(User entity); method?
ID: dunno, maybe it's generated maybe it's not
Name/FirstName: well those should be set
Password: is that a plain-text password, an hashed version? what is it?
IsDeleted/IsActive: should I activate the user myself? Is is done by the business method?
Profiles: hum... how do I affect a profile to a user?
Events: the hell is that??
It forces you to not use lazy loading
Yes, I hate this feature for multiple reasons. Some of them are:
extremely hard to use efficiently. I've seen too much times code that produces thousands of SQL request because the developers didn't know how to properly use lazy loading
extremely hard to manage exceptions. By allowing SQL requests to be executed at any time (i.e. when you lazy load), you delegate the role of managing database exceptions to the upper layer, i.e. the business layer or even the application. A bad habit.
Using POCO forces you to eager-load your entities, much better IMO.
About AutoMapper
AutoMapper is a tool that allows you to automagically convert Entities to POCOs and vice et versa. I do not like it either. See https://stackoverflow.com/a/32459232/870604

I have a counter-question: Why not both?
Consider any arbitrary MVC application. In the model and controller layer you'll generally want to use the EF objects. If you defined them using Code First, you've essentially defined how they are used in your application first and then designed your persistence layer to accurately save the changes you need in your application.
Now consider serving these objects to the View layer. The views may or may not reflect your objects, or an aggregation of your working objects. This often leads to POCOS/DTO's that captures whatever is needed in the view. Another scenario is when you want to publish objects in a web service. Many frameworks provide easy serialization on poco classes in which case you typically either need to 1) annotate your EF classes or 2) make DTO's.
Also be aware that any lazy loading you may have on your EF classes is lost when you use POCOS or if you close your context.

Entity Framework: storing as a list of complex type

I am kinda new with entity framework, I have the following scenario which I want to persist on DB with entity framework:
public class Period
{
public Period() { }
public DateTime From { get; set; }
public DateTime To { get; set; }
}
public class Class1
{
public Period Validity {get; set;}
}
public class Class2
{
public List<Period> Validities {get;set;}
}
I can persist Class1 configuring Period as a complex type, but then I cannot persist Class2.
I can persist Class2 configuring Period as an Entity, but then Class1 doesn't work when trying to add Class1.
And also, Period is not an entity, I don't want to treat it as an entity, I don't want to place an ID on Period, because my model has no sense with it. It was a struct and I has to make it become a class, already.
I would like to keep my existing model as it is now.
Is it there a workaround or something that can allow me to define mapping at a lower level?
Would it be possible with NHibernate 4? I am ready to switch my all persistence layer to nhibernate, if worth it!
Any hints?

If you try to squeeze your (non-anemic) domain model into an ORM, you will always have to make compromises. So this is usually not a good idea except for very simple applications.
Create a persistence model that consists of dead-simple, getter-setter-only classes without any logic. Make them in a way that fits EF well and use them to persist data. Now map your persistence model to your domain model an vice-versa.
This may seem like overkill, but is the only clean solution if you really want to apply DDD. Try to keep the two models close, so that the mapping is simple. Automapper is a good tool for this kind of model-to-model mapping.

You can't do exactly what you ask in NHibernate, but we know ORMs are all about tradeoffs. What do you really gain from Period having no ID ? Are you ever going to try to equate a Period from Class1 with a Period from Class2 using value equality ?
I usually care a lot more about the semantic benefit of VO's than their shape (no ID, comparison by value, etc.) In other words, I think making domain concepts explicit by grouping anonymous primitive values into well-named VO's is more important than not mistaking Entities for Value Objects or the other way around.
Thus I'm willing to sacrifice a bit of "purity" to still get the benefits of an ORM and not have to create an extra "data model" layer and the extra mapping that goes with it.
This doesn't mean you shouldn't try to find sense in Period being an Entity. Depending on your context, it may be possible. This article shows a solution where the VO is treated as a NHibernate Component when seen from its host object but as an Entity when created/edited. It might be a good middle ground option.