Я работаю в системе клиент / сервер:
Существует база данных, сервер приложений и приложение интерфейса пользователя (клиента). Сервер приложений обрабатывает соединения от клиентских приложений, которые, в свою очередь, обращаются к базе данных, когда клиентское приложение запрашивает, например, список пользователей или определенный объект по идентификатору.
В настоящее время у меня есть набор объектов данных, таких как «пользователь», «область» и т. Д., Которые отображаются на таблицы в базе данных. Эти объекты данных определяются в общей библиотеке, которая связывается с клиентом и сервером приложений при компиляции. Они наследуют класс, который позволяет сериализовать их, чтобы они могли проходить между клиентом и сервером, и они принимают «поставщика данных» как внедрение зависимостей, чтобы разрешить фиксацию либо отправить на сервер приложений, либо отправить в базу данных в зависимости от того, они используются на стороне клиента или сервера.
Когда пользователь клиентского приложения хочет отредактировать пользователя, он запрашивает этот объект у сервера приложений, использует его для заполнения пользовательского интерфейса текущими значениями, позволяет пользователю редактировать эти значения и затем «фиксирует» объект возвращается к серверу приложений, который в свою очередь фиксирует его в базе данных.
Это хорошо для этого очень простого сценария, но по мере усложнения пользовательский интерфейс будет нуждаться в объектах, которые, возможно, состоят из нескольких объектов базы данных нижнего уровня, поэтому я думаю, что мне нужно абстрагироваться от модели базы данных. до некоторой степени.
В таком случае я не должен передавать то, что, я полагаю, будет называться объектами "DAL" в пользовательский интерфейс (через сериализацию), поэтому я думаю, что мне нужны некоторые DTO (объекты передачи данных).
Я также нахожу в сервисе приложений, где я делаю бизнес-логику, в настоящее время я обрабатываю все это, переключая тип объекта, передаваемого клиентом, делая все необходимое и затем фиксируя в базе данных. Я думаю, возможно, здесь мне вместо этого нужны бизнес-объекты, каждый из которых знает, как проверять и действовать.
Так что я, возможно, в итоге получу:
Shared:
* UserDTO (data transfer object)
Application Server:
* UserDAL (data access object)
* UserBO (business object, contains UserDAL)
* UserDTO (data transfer object as defined in shared lib)
Client:
* UserDTO (data transfer object as defined in shared lib)
Итак, клиент запрашивает пользовательский DTO, отображает или обновляет как необходимый, вызывается метод "save", он сериализуется и отправляется на сервер приложений, который десериализует его, создает бизнес-объект, который делает все, что ему нравится. с ним (например, проверить, сохранить в БД и т. д.).
Это означает удаление всей моей логики сериализации из объектов DAL в объекты DTO и удаление моего класса большой бизнес-логики, и на уровне представления (клиенту) не нужно будет ничего знать о структуре базы данных.
Озвучено ли это правильно?
Кто-то еще предложил иметь бизнес-объекты в общей библиотеке и не иметь объектов передачи данных. Однако проблема в том, что у меня есть бизнес-логика в 2 местах, и было бы неплохо иметь возможность обновлять бизнес-логику в одном месте, вместо того, чтобы потенциально обновлять сотни клиентских приложений, взаимодействующих с одной службой приложений. Это также означает, что у бизнес-объектов также должны быть все процедуры получения / установки объектов DTO.
Надеюсь, это имеет смысл. Любые мысли будут оценены: -)