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

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

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

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

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

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

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

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

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

Я сделаю это:

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

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

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

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

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

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

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

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