обновить БД из многоуровневой архитектуры: лучший подход?

Question

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

Другие способы, о которых я думал:

1. передать бизнес-объект в соответствующую службу данных, там выполнить SP со всеми значениями в качестве параметров. - отстой, потому что я должен передать бизнес-объект в DAL (нарушая разделение) и, вероятно, в итоге получит SP с> 50 параметрами

2. создать пустой (?) Набор данных в бизнес-объекте, заполнить его значениями из бизнес-объекта, передать этот набор данных в службу данных и обновить базу данных с помощью адаптера данных. Я думал о создании пустого набора данных с строкой «... WHERE 0» -SQL. Это будет хорошей практикой?

Впервые я делаю что-то подобное. Последнее звучит лучше для меня, но, может быть, есть другие, лучшие подходы? Или первый лучше по некоторым причинам, я не знаю?

Большое спасибо!

[edit:] Я не могу использовать LinQ2SQL, потому что я использую C # Express (который поддерживает только запросы к локальным БД, а моя удаленная)

Answer 1

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

Answer 2

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

Вас беспокоит необходимость передать слишком много параметров в методы DAL, а затем упомянуть пример, в котором вам нужно только передать 2 или 3 значения. Если это так, то передача его в качестве аргументов метода является разумной. Если вы передаете больше значений, один из способов добиться этого - определить интерфейс с подмножеством значений, которые вы хотите сохранить. Таким образом, вы четко указываете информацию, которую будет обрабатывать метод.

Независимо от вышесказанного, не делайте методы слишком специфичными, так как в итоге вы получите множество комбинаций, которые могут усложнить управление.

Answer 3

Вы не упомянули об использовании LINQ. Это потому, что вы еще не используете .NET 3.5?

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

Answer 4

Если ваш уровень доступа к данным не является очень общим, как будет плохо передавать бизнес-объект?

Я фанат сериализации объекта и передачи XML в хранимый процесс, но, вероятно, я буду в меньшинстве.

Answer 5

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

также вы можете попробовать linq2SQL таким образом, чтобы забыть о параметрах, и это уменьшит количество ваших SP.