LINQ Entities как бизнес-объекты - за / против

Question

dbml-файл, сгенерированный Visual Studio (sqlmetal), содержит сущности, сопоставленные с таблицами базы данных. По вашему мнению, эти предложения подходят для использования в качестве классов модели предметной области? Или мы должны избегать их и изолировать их только на уровне доступа к данным?

Спасибо

Answer 1

В большинстве случаев уровень сладкого совершенства между объектами сущности и написанием SQL равен вашему DAL. Вся цель LINQ - предоставить вашему DAL гораздо больше выразительных конструкций, чем это было возможно в прошлом.

Без LINQ, в вашем BL вы можете быть ограничены вызовами методов, такими как GetCustomersByLastName(string) против вашего DAL. Единственная причина, по которой вы пишете этот метод, заключается в том, что где-то в вашем BL вам нужно искать клиентов по фамилии. Это означает, что ваши контракты DAL явно обусловлены потребностями BL. Принимая во внимание, что с LINQ вы освобождаетесь от конкретной зависимости между потребностями BL и контрактами DAL. DAL может быть абсолютно независимым в отношении конкретного использования; он просто раскрывает контракты сущностей и их отношения, и БЛ использует их по своему усмотрению, не заботясь об их реализации данных. Это истинное разделение интересов.

Если вы скрываете силу LINQ за традиционным DAL, какой смысл вообще использовать LINQ?

Answer 2

Для достаточно простого приложения большой плюс непосредственного использования сущностей LINQ - простота. Вы можете избежать использования еще одного слоя в своем коде, вы можете избежать написания большого количества шаблонной логики для сопоставления вашего бизнес-объекта вашим сущностям LINQ (хотя существуют такие инструменты, как AutoMapper , которые могут очень помочь здесь).

С другой стороны, как вы говорите, ваша база данных, вероятно, не является точным изображением вашей доменной модели. Опять же, если вам нужна эта возможность для сопоставления между конкретной физической моделью базы данных и моделью логического домена, возможно, вам стоит взглянуть на Entity Framework вместо этого? Это и есть основа EF - эти две модели и слой отображения между ними.

Марк

Answer 3

Это зависит

Если ваши доменные объекты очень простые и ваш проект небольшой, то использование этих классов не проблема. Было бы напрасной тратой времени написать целый дополнительный слой, который бы просто повторял эти классы.

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

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

Answer 4

Я думаю, это зависит от сценариев.

Сейчас я пишу сервис WCF, моя модель данных не очень сложная, но все таблицы имеют внешние ключи, а связи между таблицами заставляют linq создавать довольно сложное дерево объектов.

С точки зрения клиента не имеет смысла извлекать все это дерево объектов, а также возвращаемое xml-сообщение будет довольно тяжелым (поэтому, если я не изменю максимально допустимое значение размера сообщения, я получаю ошибки).

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