Доменная логика против проверки данных - PullRequest
Новая
       29

Доменная логика против проверки данных

6 голосов
/ 19 марта 2012

Я занят чтением и наслаждаюсь инъекцией зависимостей в .Net Марка Симэнна.

Мне довольно сложно объяснить точный контекст, поэтому, пожалуйста, задавайте этот вопрос, только если вы знакомы скнига.

Мой вопрос касается двух классов Product в главе 2, стр. 49. Один из них находится на уровне домена, а другой - на уровне доступа к данным.Объясняется, что класс Product на уровне доступа к данным был создан мастером Linq to Entity.

Я работаю с Linq to SQL, и я мог бы украсить свой класс модели атрибутами Ling to SQL, чтобы у меня не было второго класса.Например, 

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

Однако я чувствую, что это смешивает проблемы, и в действительности это будет тесно связывать мой уровень домена с уровнем доступа к данным Linq to SQL.Согласны ли вы с этим?

Предположим, я создаю два класса 'Customer' для уровня домена и уровня доступа к данным.Скажем, город является обязательным полем.При сохранении это правило необходимо проверить.Должно ли это быть сделано на уровне домена или на уровне доступа к данным, или на обоих?

Спасибо, Дарин

Ответы [ 2 ]

6 голосов
/ 19 марта 2012

Однако я чувствую, что это смешивает проблемы, и в действительности это будет тесно связывать мой уровень домена с уровнем доступа к данным Linq to SQL.Вы согласны с этим?

Да, так и будет.Как Entity Framework (сначала код), так и nhibernate могут использовать отдельные классы отображения, которые позволили бы очистить ваши модели без зависимостей от OR / M.

Примечание: у моделей домена не должно быть открытых установщиков для свойств (вDDD).Поскольку он эффективно перемещает логику модели за пределы модели.

Давайте предположим, что я создаю два класса Customer для домена и уровня доступа к данным.Скажем, город является обязательным полем.При сохранении это правило необходимо проверить.Должно ли это быть сделано на уровне домена или на уровне доступа к данным, или на обоих уровнях?

Сущность базы данных должна существовать только в пределах классов репозитория, и поэтому ее необязательно проверять.Сохраняемая модель домена уже должна иметь правильное состояние.

Пример: 

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);
    }
}
5 голосов
/ 19 марта 2012

Абсолютно, это связывает ваш уровень домена с DAL. Хуже того, сущности вашего доменного уровня будут иметь ту же структуру, что и таблицы в вашей БД. Если эти таблицы являются реляционными, то это не будет лучшим представлением модели предметной области.

Что мы делаем, это позволяем сущностям Linq-SQL существовать в DAL, а затем у нас есть классы отображения в DAL, которые преобразуют сущности L2S в доменные сущности и наоборот. И это нормально, потому что DAL действительно является вашим ORM, и часть его работы заключается в том, чтобы сделать это отображение.

Я бы сказал, что если City требуется, как бизнес-правило, то это бизнес-логика и принадлежит как бизнес-правило на уровне бизнес-логики. Существуют пакеты проверки, которые могут помочь с этой проблемой.

...