CODEWITHSUNDEEP
c#linqarchitecturedomain-driven-designentity
Daryn
Daryn

Reputation: 3768

Domain logic vs data validation

I am busy reading, and enjoying, Dependency Injection in .Net by Mark Seemann.

It is quite difficult for me to explain the exact context, so please only bother with this question if you are familiar with the book.

My question has to do with the two Product classes in chapter 2 pg 49. There is one in the Domain layer and one in the data access layer. It is explained that Product class in the data access layer was created by the Linq to Entity wizard.

I am working with Linq to SQL, and I could adorn my model class with Ling to SQL attributes, so that I don't have to have a second class. E.g.

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

However I feel this is mixing concerns and it will in effect tightly couple my domain layer to the Linq to SQL data access layer. Do you agree with this?

Let's assume I create two 'Customer' classes, for the domain and data access layer. Let's say City is a required field. When saving, this rule needs to be checked. Should this be done in the domain layer or the data access layer, or both?

Thanks, Daryn

Upvotes: 6

Views: 774

Answers (2)

jgauffin
jgauffin

Reputation: 101130

However I feel this is mixing concerns and it will in effect tightly couple my domain layer to the Linq to SQL data access layer. Do you agree with this?

Yes, it would. Both Entity Framework (code first) and nhibernate can use seperate mapping classes which would make your models clean without dependencies to the OR/M.

A side note: Domain models should not have public setters for the properties (in DDD). Since it effectively moves the model logic to outside the model.

Let's assume I create two 'Customer' classes, for the domain and data access layer. Let's say City is a required field. When saving, this rule needs to be checked. Should this be done in the domain layer or the data access layer, or both?

The database entity should only exist within the repository classes and it's therefore not necessarily to validate it. The domain model which is being saved should already have 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);
    }
}

Upvotes: 6

Bob Horn
Bob Horn

Reputation: 34297

Absolutely, that couples your domain layer to the DAL. Even worse, your domain layer entities will have the same structure as the tables in your DB. If those tables are relational, then that won't be the best representation of a domain model.

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

I would say that if City is required, as a business rule, then that's business logic and belongs as a business rule in the business logic layer. There are validation packages out there that can help with this issue.

Upvotes: 5

Related Questions