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

Question

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

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

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

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

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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

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

Я делаю это:

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

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

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