даю веб-приложение MVC (с использованием среды Spring MVC), и я немного озадачен лучшим способом проектирования конкретной области.

Приложение должно взаимодействовать с серией веб-сервисов, которые на самом деле не очень хорошо разработаны, и не предлагают много абстракций сами по себе - в основном, есть метод веб-сервиса для каждой операции создания / обновления / получения / удаления для каждый "тип данных", и кроме этого не так уж много API. Клиент веб-службы должен знать, какие методы вызывать и в каком порядке, чтобы иметь возможность создавать необходимые ему данные - другими словами, нет методов, основанных на «транзакциях».

Например, просто для создания новой учетной записи пользователя необходимо вызвать всего семь различных методов веб-службы, чтобы настроить все записи в необходимых таблицах (user запись, добавив правильныйprivileges для этого пользователя, настройка пользователяbilling детали и т. д.).

Я борюсь с лучшим способом абстрагировать это и инкапсулировать это в нашем приложении. Большая часть приложения следует стандартному потоку:

request ---> Controller <---> Service/Business-level object <---> DAOs for data access

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

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

В настоящее время я только разработал это создание "обычного пользователя", как подтверждение концепции - у меня есть объект доменаUser,UserDao интерфейс, который имеет методы дляgetUser(name) а такжеcreateUser(User)иWebServiceUserDao который реализуетUserDao методы и знает, как вызвать вышеупомянутые семь методов веб-службы.createUser() метод вызываетсяUserCreationService, который является моим классом уровня бизнеса / обслуживания, который в свою очередь вызываетсяSignupController.

Но расширить эту логику, чтобы иметь возможность создавать разные типы пользователей (которые представлены разными значениями вUser.getType()Я не уверен, где провести черту между классом уровня бизнес / сервис и DAO. Например, я должен:

СоздайUserDao реализации для каждого «пользовательского типа», поэтому логику для создания каждого «пользовательского типа» можно инкапсулировать в своем собственном классе, и позволитьUserCreationService решить, какойUserDao использовать? Это будет соответствовать 1 классу обслуживания: много DAO.Должен ли я сломатьUserDao на более мелкие части, по одной на каждую «запись», которая должна быть создана в веб-сервисе / БД, даже если моему общему приложению не нужно знать о каждом из этих отдельных типов? А потом уже разныеUserCreationService реализации для различных "пользовательских типов"? Другими словами, эта стратегия будет иметьPrivilegesDao,BillingPlanDaoи т. д., хотя у меня не было бы необходимости в соответствующемPrivilege или жеBillingPlan доменный объект. Это будет много классов обслуживания: много DAO.Содержат всю логику, для которой нужно вызывать веб-сервисы для каждого «типа пользователя» в одномWebServiceUserDao? Это может иметь недостаток наличия очень сложного класса (а PMD уже жалуется на цикломатическую сложность), но вся эта логика будет инкапсулирована в одном классе и может привести к меньшим сложностям при рассмотрении с общей точки зрения API.

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

Есть мнения? Какие стратегии вы используете, когда решаете, где разделить «бизнес-логику» и «логику доступа к данным», когда они, кажется, пересекаются?