Domain logic versus data validation

Question

I am busy reading and enjoying, Injecting dependencies in .Net by Mark Seman.

It's hard for me to explain the exact context, so please just ask this question if you are familiar with the book.

My question is related to the two Product classes in chapter 2 pg 49. There are one and one at the data access level in the domain layer. It is explained that the Product class at the data access level was created by the Linq to Entity wizard.

I work with Linq for SQL, and I could beautify my model class with Ling to SQL attributes, so I don't need to have a second class. For instance.

[Table(Name="Customers")] public class Customer { [Column(IsPrimaryKey=true)] public string CustomerID; [Column] public string City; } 

However, I feel that this is confusing issues, and it will greatly affect my level of access to the Linq to SQL data access level. Do you agree with that?

Suppose I create two classes "Client" for the level of access to domains and data. Let them say that the City is a required field. When saving, this rule must be checked. Should this be done at the domain level or at the data access level, or both?

Thanks Darin

Answer 1

Absolutely what connects your domain level with DAL. Even worse, your domain level objects will have the same structure as the tables in your database. If these tables are relational, then this will not be the best representation of the domain model.

What we do is let Linq-to-SQL objects exist in the DAL, and then we have mapping classes in the DAL that convert L2S objects to domain objects, and vice versa. And that's good, because DAL is actually your ORM, and part of its job is to do this mapping.

I would say that if City is required as a business rule, then this business logic is included in the business rule at the level of business logic. There are validation packages that can help with this problem.

Answer 2

However, I feel that this is confusing issues, and it will greatly affect my level of access to the Linq to SQL data access level. Do you agree with that?

Yes it would. Both Entity Framework (first code) and nhibernate can use separate mapping classes that will make your models clean without dependencies with OR / M.

Note: domain models must not have public settings for properties (in DDD). Because it effectively moves model logic outside the model.

Suppose I create two classes "Client" for the level of access to domains and data. Let them say that the City is a required field. When saving, this rule must be checked. Should this be done at the domain level or at the data access level, or both?

The database object must exist only in the repository classes and therefore it is not necessary to validate it. The saved domain model must be in the correct state.

Example:

 public class ArticleRepository { public void Save(Article article) { // Article is already in a correct state // (thanks to no public setters) var dbEntity = new ArticleEntity(); Mapper.Map(article, dbEntity); _dbContext.Save(dbEntity); } }