, где данные должны располагаться в n-уровневой (многоуровневой) архитектуре?

Question

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

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

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

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

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

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

Answer 1

Где я нахожусь, мы возвращаем наборы данных, datasables, datarows и datareaders из слоя данных в бизнес-уровень.

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

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

---

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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

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

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

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

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

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

Answer 6

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

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

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