где наборы данных должны находиться в n-уровневой (многоуровневой) архитектуре? - PullRequest
4 голосов
/ 08 мая 2009

В настоящее время мы обсуждали вопрос о том, должен ли набор данных идти на уровне данных или на уровне бизнеса?

Мой друг считает, что все компоненты ADO.NET должны идти на уровне данных. Для меня это кажется неправильным по следующим причинам:

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

Я думаю, что наборы данных и таблицы данных должны быть в бизнес-логике, поскольку они являются общими для всех поставщиков данных. Уровень данных должен иметь Фабрику провайдеров для создания экземпляров объектов соответствующего провайдера (Connection, DataAdapters, Transactions, DataReaders и т. Д.). Для меня это путь по следующим причинам:

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

Может ли какой-нибудь n-уровневый гуру помочь нам разобраться, по какому пути идти? Заранее спасибо

Ответы [ 6 ]

5 голосов
/ 08 мая 2009

По моему мнению, вообще не используйте DataSet. Даже не используйте типизированный DataSet. Это старые конструкции, созданные до LINQ. Пропустите древнюю историю и погрузитесь в настоящее время: используйте LINQ to Entities и Entity Framework (EF). Они тесно связаны, но не одинаковы.

Не показывать объект EF через границу службы. К сожалению, Microsoft решила раскрыть детали реализации при сериализации объекта. Кроме того, используйте EF и получайте гораздо больше удовольствия, чем с DataSet.

2 голосов
/ 08 мая 2009

Что ж, изоляция доступа к данным не нова: мы делаем это 15 лет назад (да, 15 лет назад!).

Я работал во многих местах и ​​видел много изолированных слоев данных.

Но я никогда - никогда! - видел замену источника данных!

Да, я видел это дважды: и дважды мы также заменяем устаревший слой данных и все программное обеспечение для заполнения ...

Мой ответ довольно прост: если вы не работаете с полочными программами, вы можете изолировать столько, сколько вам нужно, слой данных, вы сделаете это даром.

Ни за что, потому что никто не изменит SQL Server или Oracle только ради изменений. И ни за что, потому что в тот день, когда кто-то сделает это, он либо перепишет свое программное обеспечение, либо убедится, что приобретаемый продукт совместим с продуктом, который он разрабатывает.

В моих книгах любой слой данных глуп.

Если вы не согласны с этим, просто скажите мне, когда в вашей жизни этот слой сэкономит кому-то $$$ ...

1 голос
/ 08 мая 2009

Там, где я нахожусь, мы возвращаем наборы данных, таблицы данных, базы данных и устройства чтения данных из уровня данных в бизнес-уровень.

Смысл в том, что эти типы не специфичны для db-flavor. Используете ли вы mysql, access, sql server, oracle или любой другой набор данных, который является набором данных, и, следовательно, можно вернуться с уровня данных корневого уровня.

Затем бизнес-уровень берет эти необработанные данные и превращает их в строго типизированные бизнес-объекты & mdash; применение любых необходимых бизнес-правил & mdash; передать на уровень представления.


Редактировать: Когда я просматриваю некоторый код, мы не используем много полного набора данных. В основном это datatables и datareaders.

0 голосов
/ 08 мая 2009

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

Если вы предоставляете DataSet фактическому коду рендеринга страницы, вы фактически выставляете схему базы данных (конечную основу продукта) на уровне представления. Теперь может возникнуть очевидная проблема: позже вы захотите реструктурировать базовую схему данных, и из-за дизайна вам нужно будет применить изменения ко всем другим слоям в системе. Это яркий пример того, что инкапсуляция не используется, когда она действительно должна быть.

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

0 голосов
/ 08 мая 2009

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

0 голосов
/ 08 мая 2009

Типичный подход состоит в том, чтобы представить интерфейс хранилища агрегированного корня (например, Customer) в уровне / области вашего бизнес-логики и внедрить конкретные хранилища в уровне / инфраструктуре доступа к данным.

...