Объекты между Data- и BusinessLayer

Question

Я на начальной стадии нового проекта. Поскольку я всегда хочу улучшать себя и стараться избегать ошибок прошлого (у каждого есть свой багаж), я посмотрел Пример многоуровневой архитектуры для .NET . Глядя на данные и бизнес-логику, я заметил, что уровень данных действительно имеет ссылку на сборку ExpenseSample.Business.Entities, поэтому уровень данных знает, что существует бизнес-уровень. Это выглядит и чувствует себя немного неловко.

Конечно, это экономит время, сопоставляя DataObject с BusinessEntities, но не является ли «опасным» подходом?

Будем рады некоторому обсуждению и, возможно, лучшим решениям.

UPDATE: Спасибо за вклад. Я сейчас использую

MyApp.Data.Contracts.*
MyApp.Data.Access.*         /* has the classes to access the DB and maps it to 
                               the Data.Contracts */
MyApp.Business.Entities.*
MyApp.Business.Components.* /* accesses the classes from Data.Access, 
                               maps the Contracts to the Business.Entities and 
                               provides the components to access them */

Таким образом, я могу убедиться, что внутренние изменения в представлении моих данных не влияют на внешние слои.

Answer 1

Я не согласен, некоторые объекты должны быть доступны для всех слоев, я делаю это так:

-----------
| DAL | E  |
------- N  |
| BAL | T  |
------- I  |
|  G  | T  |
|  U  | I  |
|  I  | E  |
|     | S  |
-----------

DAL обычно подключается к службе WCF и защищает остальную часть приложения от его знания (поэтому его можно изменить через несколько лет, если WCF устарел).

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

Конечно, это для довольно небольшого приложения, оно может быть расширено другими библиотеками (модулями, сторонними разработчиками и т. Д.) И может быть гораздо более сложным, но это идея.

Полагаю, я пытаюсь сказать, что сущности и BAL - это две разные вещи, не путайте их;)

Answer 2

Общее правило состоит в том, что нижний уровень не должен знать о верхних слоях. Пример неверен, так как бизнес-объекты являются частью BAL, а не DAL. Следовательно, бизнес-уровень должен выполнять сопоставление, а не уровень данных.

Отображение на самом деле не требует времени, просто используйте что-то вроде ValueInjecter

Отказ от ответственности: я не смотрел на связанный образец. Просто даю два моих цента за наслоение в целом.

Answer 3

... поэтому уровень данных знает, что существует бизнес-уровень

Не совсем правильно, просто известно, что есть пространство имен с именем Business.Entities, но эти объекты, безусловно, являются листами в архитектуре. Они зависят ни от чего, кроме .Net Framework. Сущности на самом деле не имеют никакой логики (кроме ToString ()), поэтому они просто действуют как контракты данных для всей архитектуры. Также они свободны от ссылок на любые другие проекты. Единственное, что не делает их POCO, это то, что они поддерживают сериализацию.

Как упомянул Бабун, такой подход возможен, и я уверен, что есть примеры, где он работает очень хорошо. И если вы посмотрите на проект и код, то все выглядит так красиво и уютно, что я просто хочу влюбиться в него.

И это будет хорошо и упорядоченно, если вы тщательно спланируете каждое добавление ко всей вашей архитектуре, просмотрите все изменения и будете тесно общаться с разработчиками. Но как только ваша архитектура, база данных и ваши бизнес-процессы будут развиваться более быстрыми темпами, вам придется далеко продвинуться, чтобы смоделировать данные для всех этих слоев с общими объектами. Есть несколько примеров, которые, на мой взгляд, говорят в пользу контрактов на данные уровня. Среди них то, что однажды программист пользовательского интерфейса захочет иметь в ваших объектах уведомления PropertyChanged для своего слоя пользовательского интерфейса. Hrmpf! Вы не можете сделать это, не влияя также на ваш BAL и DAL. В другой день вы сталкиваетесь с тем, что вы хотите, чтобы в объектах хранились свойства только с графическим интерфейсом (например, цвет отображения, положение на экране, состояния выбора и т. Д.). При чем тут база данных? И если вы внимательно посмотрели, то заметили, что у сущностей уже есть специфичные для слоя обработки. Вы видели виртуальные ключевые слова в свойствах навигации? Они существуют для того, чтобы EF мог создавать их подклассы и предоставлять вам прокси-классы с отложенной загрузкой ... которые, в свою очередь, скорее всего не предназначены для передачи через службу.

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

Answer 4

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

В большинстве проектов, над которыми я работал, было мало пользы в разделении BAL и DAL на отдельные сборки. Если ваше решение для базы данных может измениться, и вы хотите самостоятельно ориентироваться на будущее, используйте взамен ORM, например, nHibernate.