Лучшие практики на уровне данных

Question

Я нахожусь в разгаре "дискуссии" с коллегой о наилучшем способе реализации уровня данных в новом приложении.

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

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

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

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

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

ТИА

Answer 1

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

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

Я делаю это:

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

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

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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