architecture - pattern - entity framework dal



DAL/BLL и клиент/сервер: должен ли клиент использовать объекты BLL или DAL для презентации? Или, может быть, другой слой(объект передачи данных?) (1)

Я пишу систему клиент / сервер. Сервер имеет дизайн DAL / BLL. Клиент отвечает за представление объектов данных и предоставление диалогов и мастера, позволяющих пользователю обновлять эти объекты (например, добавлять / редактировать пользователя).

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

Таким образом, объект изменяется на уровне презентации, например «пользователь»: user-> setName («Fred»), а затем совершает его, как этот user-> commit (), метод фиксации вызывает метод фиксации поставщика данных, который затем кодирует объект и отправляет его на сервер. Затем сервер «украшает» объект бизнес-уровня и продолжается оттуда.

В настоящее время я работаю как прототип, с объектами DAL, определенными в совместном проекте, который используется как клиентом, так и сервером. Затем сервер вводит свой поставщик данных (который использует базу данных), а клиент внедряет поставщика данных, который использует сервер.

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

Благодарю.


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