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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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