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

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

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

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

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

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

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

ТИА

14.08.2008 10:23:05
8 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

5
14.08.2008 10:38:04
Я полностью согласен. Дизайн слоев доступа к данным и т. Д. Становится немного размытым. Принимая во внимание, что я всегда хотел бы отделить вашу бизнес-логику от уровней представления. Шаблон MVC FTW ;-)
Tobias N. Sasse 26.08.2012 17:58:21

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

1
14.08.2008 10:27:50

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

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

Я сделаю это:

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

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

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

0
14.08.2008 10:28:08

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

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

0
14.08.2008 10:28:20

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

3
14.08.2008 10:28:43

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

1
14.08.2008 10:30:21

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

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

0
14.08.2008 10:30:51

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

0
11.10.2008 13:24:06