Я працював із SpringMVC, Hibernate та деякими базами даних на прикладі веб-додатків Java.
Є кілька різних, які роблять це, але цей весна 3 та підручник із інтеграції зі сплячим зі прикладом має клас моделі, вид (у jsp) та класи та сервіси та дао для контролера.
Моє запитання: чи не сервіс, а класи DAO не роблять те саме? Навіщо тобі вони обоє потрібні?
Це був підручник, який я фактично використовував: http://fruzenshtein.com/spring-mvc-security-mysql-hibernate/
Відповіді:
Як правило, DAO є максимально легким і існує виключно для забезпечення з'єднання з БД, іноді абстрагуванням, тому можуть використовуватися різні пакети БД.
Службовий рівень є для забезпечення логіки роботи з даними, що надсилаються в DAO і клієнту. Дуже часто ці 2 частини будуть поєднані в один модуль, а іноді і в той самий код, але ви все одно будете бачити їх як окремі логічні об'єкти.
Інша причина - безпека. Якщо ви надаєте сервісний рівень, який не має відношення до БД, то важче отримати доступ до БД від клієнта, крім служби. Якщо в БД неможливо отримати доступ безпосередньо від клієнта (і не існує тривіального модуля DAO, який виступає в якості сервісу), то всі зловмисники, які взяли на себе клієнта, можуть зробити це спроба зламати сервісний рівень, перш ніж він отримує все, крім найбільш оздоровлений доступ до ваших даних.
Я письменник питання, про який йде мова. Я маю неабияку частку роботи над різними технологіями та різними архітектурами. Виходячи з вищесказаного, я сміливо можу сказати, що наявність рівня обслуговування та шару дао завжди є хорошою ідеєю. DAO слід обмежувати лише додаванням / оновленням / вставкою / вибором об'єктів Entity в / з бази даних, і це все. Якщо ви хочете зробити щось додаткове з точки зору логіки, додайте це до рівня обслуговування. Це допоможе зробити код модульним і легкозамінним при заміні бази даних (для певної частини даних). Це особливо застосовно у додатках, що включають звіти, які мають важку логіку навіть після отримання даних із бази даних.
Також навесні безпека застосовується на рівні обслуговування в ідеалі. Ви б не хотіли змінювати цей спосіб.
Адам Бієн вказує у своїй книзі на те, що JPA EntityManager є доброю універсальною реалізацією DAO:
У світі Java EE майже ніколи не потрібно писати свій власний DAO, оскільки реалізація JPA включає його. Вам потрібно лише написати рівень обслуговування.
Реалізація власного шару DAO - це справді похмілля від дуже бідної архітектури J2EE 15 років тому, але багато людей все ще відчувають себе змушеними це робити. Ці користувацькі шари DAO часто пропонують не що інше, як функції переадресації, які викликають відповідний метод в EntityManager.
Отже, щоб відповісти на ваше запитання, так, вам потрібен рівень обслуговування та DAO, але вам потрібно лише написати сервісний рівень.
Я виявив, що рівень обслуговування додає зайву складність у більшості випадків. Теоретично - уникати логіки бізнесу в шарі дао, але в кінцевому підсумку це просто призводить до плутанини, навіть деякі люди зловживають, щоб повністю видалити шар дао, оскільки вони вважають, що це не додає цінності. http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer
Але якщо у вас є декілька логік бізнесу, то так, це гарна ідея. Наскільки важливо зробити рівень обслуговування?
IMHO Сервісний рівень може розглядатися як шар між контролером і шаром DAO. Цей сервісний шар саме там, де ми можемо додати ділову логіку і навіть створити об'єкт повернення, специфічний для того, що має бути надано представленням.