Рекомендации по уровню данных

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

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

Противоположная точка зрения состоит в том, что уровень данных должен быть объектно-агностическим и обрабатывать только простые типы данных (строки, логические значения, даты и т. Д.).

Я вижу, что оба подхода могут быть действительными, но моя собственная точка зрения такова, что я предпочитаю первый. Таким образом, если среда хранения данных изменяется, бизнес-уровень (обязательно) не должен изменяться, чтобы приспособиться к новому уровню данных. Поэтому было бы тривиально перейти от хранилища данных SQL к хранилищу сериализованной файловой системы xml.

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

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

TIA

Ответов (8)

Решение

Это действительно зависит от вашего взгляда на мир - раньше я был в лагере несвязанных. DAL был там только для того, чтобы предоставить данные для BAL - в конце истории.

По мере того как новые технологии, такие как Linq to SQL и Entity Framework, становятся все более популярными, граница между DAL и BAL немного стирается. В L2S, особенно ваш DAL, довольно тесно связан с бизнес-объектами, поскольку объектная модель имеет сопоставление 1-1 с вашим полем базы данных.

Как и все в разработке программного обеспечения, нет правильного или неправильного ответа. Вы должны понимать свои требования и будущие требования и работать оттуда. Я бы больше не использовал Ferrari на ралли Дахар, как Range Rover на треке.

У меня есть отличная книга, посвященная этой теме, - это Клифтон Нок « Шаблоны доступа к данным». У него есть много хороших объяснений и хороших идей о том, как отделить ваш бизнес-уровень от уровня сохраняемости. Вам действительно стоит попробовать. Это одна из моих любимых книг.

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

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

Вы можете получить и то, и другое. Пусть уровень данных не знает ваших бизнес-объектов и сможет работать с более чем одним типом источников данных. Если вы предоставляете общий интерфейс (или абстрактный класс) для взаимодействия с данными, вы можете иметь разные реализации для каждого типа источника данных. Заводской узор здесь хорошо сочетается.

Джеффри Палермо написал об этом хороший пост. Он назвал это « Луковой архитектурой» .

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

public IList<Foo> GetFoosById(int id) { ... }

Я делаю это:

public void GetFoosById(IList<Foo> foos, int id) { ... }

Это позволяет мне передать простой старый список, если это все, что мне нужно, или более интеллектуальную реализацию IList <T> (например, ObservableCollection <T>), если я планирую выполнить привязку к нему из пользовательского интерфейса. Этот метод также позволяет мне возвращать данные из метода, такие как ValidationResult, содержащие сообщение об ошибке, если она возникла.

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

В приложениях, в которых мы используем NHibernate, ответ становится «где-то посередине», в то время как определения отображения XML (они указывают, какая таблица принадлежит какому объекту, а какие столбцы принадлежат какому полю и т. Д.) Явно находятся на уровне бизнес-объектов. .

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

Старый пост, но в поисках аналогичной информации я наткнулся на это, что хорошо это объясняет.