Сервисный слой в приложении Java Swing

Question

Я думаю, что если мне действительно нужен сервисный слой.

Я использую Spring + Hibernate для приложения для настольных качаток, и в этот момент у меня есть графический интерфейс / Swing Layer-> Service Layer-> DAO-слой. Я использую весну только для поддержки @transactional и для инъекций IOC

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

Но я понимаю, что очень часто часто сервисный слой только повторяют методы DAO, поэтому, например:

// a DAO example
@Repository
public class CustomerHibernateDAO extends BaseHibernateDAO implements CustomerDAO {

 public List<Customer> findAllCustomerILikeName(String name){
  return getSession()
   .createCriteria(Customer.class)
   .add(Restriction.ilike("name", name))
   .list();
 }
}

// Customer service to use this dao...
@Service
@Transactional
public class CustomerService {

 @Autowired
 CustomerDAO customerDAO;

 // Why i can't call DAO instead the service?
 public List<Customer> getAllCustomersByName(String name){
      return customerDAO.findAllCustomerILikeName(name);
 }

}

Это шахтное типичное использование сервисного слоя ... Hibernate DB-Agnostic, Весна - это ценнология - Агностик: Итак, мне это действительно нужно?

Как насчет уникального обслуживания класса для управления всем DAO ?? Я думаю, что это может быть хорошим компромиссом, или является плохой практикой?

Я знаю, @transactional на Дао - это плохой способ, но в этот момент я должен написать услуги только за @transactional на нем ...

РЕДАКТИРОВАТЬ

Больше инфо о моем приложении.

Мое приложение - это программное обеспечение для управления и управление регистрацией пользователя, продуктами, заказами и другими вещами, такими как те. На практике он содержит много читающих объектов-> Edit-> Сохранить объект или создание-> Редактирование-> Сохранить операции, и, благодаря гибернации, эти операции управляются одним дао в большую часть времени, потому что в гибернации с @manyto. .. Коллекция и Cascade.save_Update позволяет сэкономить два или более объектах в той же сохраненной работе.

Так, например, в моих предметах JFrame, где я могу вставить, редактировать или создать элемент (продукт для продажи) Есть:

public ItemFrame(){
 // the constructor
 itemService=springAppContext.getBeans(ItemService.class);
}

public boolean validateForm(){
 // test if the gui is correctly filled by user
}

public boolean save(){
 // create an Item entity taking value from swing gui(JTextField etc)
 Item item=new Item();
 item.setName(nameTextField.getText());
 item.setEtc...
 // ItemService ' save method is a wrap around itemDao.save(item)...
 itemService.save(item);
}

private void saveItemActionPerformed(ActionEvent evt){
 // When i press SAVE button
 if(validateForm()){
  save();
 }
}

Это то, что у меня в большинстве случаев, поэтому я думаю, что влюбился в анемично-домен-антипаттер ...

Спасибо.

Answer 1

Если ваш сервисный слой дублирует DAO, вы вообще не используете сервисный слой. В некоторых моих приложениях я сделал ту же ошибку, мне было интересно: «Почему сервисный слой выглядит так уродливо, и является дублированиемg dao" ...

Сервисный слой должен быть интерфейсом для вашего аппликации, это означает, что некоторые методы не одинаковы в DAO и в эксплуатации, но основная часть значительно отличается. Я не могу сказать это без просмотра остальной части вашего кода, но по вашему вопросу (который почти такой же, как были мои вопросы несколько месяцев назад), мне кажется, что вы используете Модель анемии домена Antipattern. Отказ В модели анемической домена ваша модель содержит только поля и полученные процедуры, без реальных методов (поведения), которые нарушают фундаментальные объектно-ориентированные принципы (объект == поведение) ... Ваше поведение, вероятно, в чем-то, что выглядит как сценарий транзакции в обслуживании слой, но должен быть в вашей модели (доменом слое).

Выход из этого является использование богатой модели домена (бобы вводят в модель через @configurable). Вы можете сказать, что это нарушает узор слоев, и вы, вероятно, верны. Но я убежден, что мы должны подумать о нашем приложении (домен + DAO + Service) как один компонент (см. Alistair Cockburn Гексагональная архитектура / порты и адаптеры).

Затем ваш WARD APP / веб-клиент будет клиентом для вашего основного компонента, вы можете затем переключать их без каких-либо ограничений (потому что данные об этом, что данные модификации в основном).

Но есть ограничение / недостаток с этим подходом. Если вы будете использовать какую-то безопасность (Spring Security) или активные записи через Hibernate, чем вы должны общаться со всеми клиентами через DTO (не сами по себе объекты), потому что когда вы обращаетесь к сущности, это может позвонить в службу, которая будет активна через транзакционный и может изменить базу данных (обойти вашу безопасность).

Я надеюсь, что я догадался, что угадал твою архитектуру, если нет, я прошу прощения за изобретение колесо здесь, но этот пост может помочь кому-то, кто не знает этого (как и немногих моли назад).

РЕДАКТИРОВАТЬ

В вашу редактирование: даже в простом приложении CRUD, некоторые действия должны быть в сервисном слое - например, валидация (не проверка «Это число», но некоторые валидации бизнеса). Это должно быть по вашему мнению, потому что если вы измените его, вы будете копировать и вставить его снова. Когда вы посмотрите на свой код, вы должны задать qeusting ", если я решил написать тонкий клиент (просмотр в веб-браузере)", есть ли какой-нибудь код, что мне придется скопировать? Если ответ Да, чем вы должны создать способ обслуживания для этого возможно удаленного вызова.

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

Пример кода (часть интерфейса службы статьи в моем приложении (Spring Security)):

@Secured("ROLE_EDITOR")
public void save(ArticleDTO selectedArticle, ArticleDetailsDTO selectedArticleDetails);

В комментарии службы все могут сэкономить свои комментарии к статьям ....

И одна последняя нота: вы, вероятно, должны учитывать, если вы нужно Сервисный слой вообще. Когда он написан хорошим способом, ваше приложение наберет много качеств в его гибкости, повторном использовании и ремонтопригодности. Но это довольно тяжело и много времени, чтобы написать это. Если вы не хотите делать это все эти вещи (безопасность, богатая домен модель, призывая с большего количества интерфейсов (изменение реализации вида)), вы можете жить без него :-)

Answer 2

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

Более того, может быть возможно сделать ваш DAO довольно общим, чтобы у вас есть только один или два метода, которые не сильно меняются. Это снижает риск чего-то ужасно неправильного к вашим классам DAO каждый раз, когда вы хотите добавить / изменить функциональность приложения.

DAO для данных доступа. Сервис предназначен для бизнес-логики. Держите их отдельно, и вы будете счастливее в долгосрочной перспективе.

Answer 3

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

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

Answer 4

Вместо того, чтобы соблюдать применение

ui -> service -> DAO

Для каждой операции считают, что позволяют оба

ui -> DAO
ui -> service -> DAO

Последнее используется для более сложных операций