Использует DTO лучший способ решить эту проблему?

Question

Я работаю над клиент-серверной системой:

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

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

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

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

В этом случае я не должен передавать то, что, как я полагаю, будет называться объектами 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, отображает или обновления как необходимому, «сохранить» вызывается метод, он получает сериализовать и направляется в сервер приложений, который де-сериализует его, создает бизнес-объект, который делает с ним все, что ему нравится (например, проверка, сохранение в DB и т. д.).

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

Звучит ли это правильно?

Кто-то еще предлагал иметь бизнес-объекты в общей библиотеке и не иметь объектов передачи данных. Проблема с этим заключается в том, что у меня есть бизнес-логика в 2-х местах, и было бы неплохо иметь возможность обновлять бизнес-логику в одном месте, вместо того, чтобы потенциально обновлять 100 клиентских приложений, говорящих с одной службой приложений. Это также означает, что бизнес-объекты должны также иметь все процедуры get/set объектов DTO.

Надеюсь, это имеет смысл. Любые мысли будут оценены :-)

Answer 1

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

Да - помещение нескольких объектов в DTO, а затем сериализация для передачи «по проводам» между клиентом/сервером звучит прямо для меня.

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

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

Да. Вы могли бы сделать то же самое между клиентом и сервером. Если вы использовали платформу Microsoft/.Net, вы можете использовать WCF, который позволяет использовать различные типы привязок, поэтому больше не будет ручной сериализации.

Проблема с этим, хотя у меня есть бизнес-логику в 2-х местах

Да havingit в двух местах не идеально - но у него есть некоторые преимущества. Одно из преимуществ дублирования некоторой бизнес-логики на стороне клиента (я думаю о правилах «проверки» здесь) заключается в том, что пользовательский интерфейс может обеспечить гораздо более интерактивный опыт для пользователей, поскольку им не придется ждать в оба конца, чтобы сообщить им, что они не могут добавить свою фамилию в поле номера телефона. Вы по-прежнему должны обеспечить правильную проверку и полный бизнес-правил на сервере: «защита в глубину», так сказать.