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

Question

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

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

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

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

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

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

Answer 1

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

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

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

---

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

В моих книгах любой уровень данных является глупым.

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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