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

Я занят чтением и наслаждаюсь инъекцией зависимостей в .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)

Ваш ответ на вопрос