Как разделить уровень данных и уровень бизнес-объектов, каковы соответствующие обязанности каждого из них?

Question

Если бы существовала такая линия бизнес-приложений, было бы это подходящим разделением труда:

Доступ к данным

• Вызывает только хранимые процедуры, отображает свойства DTOs в хеш-таблицу, которая используется для заполнения коллекций параметров команды ADO.NET.

• Только сборка с привязкой к SqlDataClient.

• Важная логика, касающаяся того, что означает пустое, нулевое и пустое значение в коде сопоставления, но, в остальном, без проверки или другой логики, специфичной для предметной области.

Так называемая бизнес-логика

• разбивает несколько наборов результатов на отдельные DataTables, например.

  общественная пустота ReturnNthRecordSetFromStoredProcFoo()

• перейти к доступу к данным для наборов данных, например.

  public void ReturnDataSet(string name){ return (новый PersonController).GetAnotherDataSet(name);}

• сопоставляет одну строку DataTable с одной DTOс

• Важная логика, касающаяся того, что означает пустое, нулевое и пустое значение в коде сопоставления.
• Содержит объект транзакции, хотя он используется исключительно для упаковки отдельных вызовов хранимых процедур.
• Не имеет ссылки на SqlDataClient, поэтому не может использовать SqlDataReaders для заполнения DTO.
• Нет ссылки на System.Web.UI
• Правила авторизации, но в остальном нет логики, специфичной для домена.

пользовательский интерфейс

• Двухсторонняя привязка данных DTO к формам ASP.NET.
• Проверка свойств элементов управления — обычно проверка непосредственно по DTO не проводится.
• Навигация по «Коллекциям» осуществляется путем привязки наборов данных к сеткам.Фактически, попытка сделать что-либо с коллекциями требует, чтобы пользовательский интерфейс перебирал DataRows в DataTables и знал, каковы соответствующие имена столбцов (которые обычно лишь отчасти похожи на DTO).

Итак, наконец, вопрос: должен ли уровень доступа к данным с этим приложением объединить обязанности так называемого бизнес-уровня? Разве это уже не двухслойное (почти одно!) приложение, если не считать неудобства лишней сборки?

Дополнительная информация:Хорошо, я уже знаю, что сервер приложений будет одним компьютером, возможно, навсегда, поскольку это приложение внутренней сети с небольшим количеством пользователей.Поэтому я знаю, что не следует проектировать физически отдельные уровни приложений.Кроме того, он, вероятно, будет поддерживать только один пользовательский интерфейс и будет полностью отменен, если когда-нибудь понадобится поддерживать что-то кроме ASP.NET — еще одна часто цитируемая причина использования уровней/уровней.

Answer 1

Мне кажется, что ответственность между уровнями немного запутана.Уровень данных звучит довольно стандартно.(«Так называемый») бизнес-уровень — это то место, где все запутывается.

Некоторые мысли о бизнес-уровне:

• Кажется, существует много представлений данных.Вы упоминаете DataTables, DataSets, объекты передачи данных.Стандартный подход ко всему приложению был бы лучше.

• Методы бизнес-уровня с такими именами, как ReturnNthRecordSetFromStoredProcFoo и ReturnDataSet, не имеют смысла и не обеспечивают соответствующий уровень абстракции для бизнес-сервисов.(Может это были просто неудачно подобранные примеры не из приложения?)

• Обычно бизнес-уровень предоставляет больше, чем просто передачу DataSet.Вместо того, чтобы иметь дело с сопоставлениями, нулями и т. д.бизнес-уровень должен сосредоточиться на проверке, бизнес-правилах, безопасности и, возможно, даже на аудите (хотя некоторые предпочитают делать это в базе данных).

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

• Я думаю, что с зависимостями все в порядке - никаких ссылок на Web.UI или SQLClient на бизнес-уровне.

• Правила авторизации тоже в порядке.Я бы расширил, включив в него безопасность, а не только авторизацию.Кроме того, я нигде не вижу никакой бизнес-логики - просто интересно, находится ли бизнес-логика в хранимых процедурах?Если бы я собирался гадать, я бы сказал «да», учитывая, что каждый бизнес-метод вызывает только одну хранимую процедуру.Если так, то для меня это большое нет-нет.

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

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

Некоторые другие вопросы, над которыми стоит подумать:какие основные проблемы вы хотите решить?Функциональны ли они (например,баги, отсутствие стабильности)?Или связано с производительностью?Или это архитектурное?Или, возможно, это связано с удобством сопровождения: вам нужно добавить новую функциональность, но это сложно?Есть ли у вас сроки или бюджет?Если вы сможете ответить на некоторые из этих вопросов, это может помочь вам.

Answer 2

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

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

Я не буду вдаваться в подробности, поскольку вам лучше самим определить, стоит ли вам использовать эту платформу, но, разумеется, у нее есть собственный класс SafeDataReader, который учитывает нули, что устраняет необходимость использовать наборы данных.

Его "портал данных» (статья старая, но все еще актуальна) позволяет легко переместить доступ к данным на отдельный уровень с минимальными усилиями и без изменения кода.

ДНРтв есть несколько видеороликов, в которых дизайнер CSLA Рокфорд Лхотка показывает работу примера приложения. Часть 1 и Часть 2.

Шоу длятся всего час каждое и, вероятно, помогут вам решить, подходит ли оно вам.

Answer 3

Я ожидаю увидеть то, что вы описываете как свой бизнес-уровень, как уровень данных.Я надеюсь, что мой уровень данных защитит меня от необходимости беспокоиться о нулях и тому подобных вещах.Я также надеюсь, что мой бизнес-уровень будет содержать более абстрактные бизнес-правила и концепции.Например, если «Группа» представляет собой набор «Пользователей», я бы хотел видеть функции бизнес-типа для управления этими Пользователями как частью группы на высоком уровне.Например, это может быть функция, которая будет назначать разрешения всем членам этой группы или позволять уровню пользовательского интерфейса применять политики к этим пользователям как к членам группы.Я бы не стал надеяться увидеть функции, которые пытаются скрыть тот факт, что все они взяты из базы данных.Я надеюсь, что это полезно.