Должны ли мы использовать одни и те же бизнес-классы на сервере и клиенте?

Question

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

Вы можете использовать DTO для передачи данных клиенту и изменениям на сервере или использовать службы WCF и создавать новые классы на клиенте.

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

Мои вопросы:

• Какой вариант вы используете и какой порекомендуете использовать в новых проектах?
• Что лучше?
• Второй лучше в некоторых случаях и как вы можете описать эти случаи?
• Сколько приложений используют первый / второй подход?
• Как выбрать в конкретном приложении?

Answer 1

Нам просто было трудно найти ответ именно на этот вопрос в нашем проекте. Это история:

Мы думали, что повторное использование классов - это замечательно и уменьшит количество повторяющихся вещей. NHibernate позволяет отсоединять и повторно подключать классы к сеансам, поэтому он кажется тривиальным.

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

• Нам пришлось реализовать некоторые приемы, потому что у сериализации, постоянства и привязки данных были свои проблемы. Это довольно уродливые хаки пошли все в те же классы. Они становились все больше и больше.

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

• Объекты неявно начали поддерживать два «режима»: DTO-режим и режим постоянства . Это стало очевидным, когда появились такие методы, как PrepareSerialization или AfterDatabaseRetrieval и другие подобные. Некоторые свойства могут использоваться только на сервере, другие - только на клиенте.

Очевидно, что обслуживание стало кошмаром. Никто больше не рискнул изменить сущность, потому что нужно было что-то менять во всей системе.

Затем мы начали переключаться на Dtos.

После огромного труда нам удалось переписать некоторые важные части системы для использования Dtos. И - вдруг все стали счастливы.

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

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

Все еще существуют тривиальные сущности и классы типа значения, которые используются как сущности и Dtos одновременно.

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

Answer 2

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

Если ваш клиентский код действительно должен выполнять логику домена , вам следует либо:

1) Десериализация напрямую в классы модели предметной области (особенно если вы используете ORM, поддерживающий постоянное невежество).

// Customer is a business object / aggregate root with domain logic
ICustomer customer = customerRepository.Get<Customer>(customerId);

2) Используйте объекты передачи данных для инициализации классов модели вашего домена:

// Given a customer data transfer object
ICustomer customer = new Customer(customerDto);

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

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

Answer 3

Я должен согласиться с предыдущими двумя ответами. Однако следует помнить об усилиях по синхронизации классов BO / DTO (я хотел бы рассмотреть возможность генерации кода).

См. Мой ответ здесь для кого-то, кто хотел пойти в другом направлении - он хотел объединить множество DTO / BO в своей системе.