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

Question

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

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

• вызывающую только хранимые процедуры, карты свойств DTO с к элементу hash tablse, которые используются для заполнения коллекций параметров команды ADO.NET.

• Только сборка со ссылкой на SqlDataClient.

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

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

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

  общественный недействительный ReturnNthRecordSetFromStoredProcFoo()

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

  общественного недействительный ReturnDataSet (имя строки) { возврата (новый PersonController) .GetAnotherDataSet (имя);}

• отображает одну строки в DataTable одному DTO сек

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

интерфейс

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

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

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

Answer 1

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

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

• Там, кажется, много представлений данных. Вы указываете DataTables, DataSets, Data Transfer Objects. Стандартный подход во всем приложении будет лучше.

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

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

DNRtv имеет несколько видеороликов, в которых дизайнер CSLA, Rockford Lhotka, показывает работу образца приложения. Part 1 и Part 2.

Показаны только час и, возможно, помогут вам решить, правильно ли это использовать.