общая даосская архитектура - лучшая практика - PullRequest
Новая
       30

общая даосская архитектура - лучшая практика

1 голос
/ 06 января 2010

я думаю об этой архитектуре

genericdao + interface ---> servicelayer + interface ---> view layer

мой дао будет иметь только общие методы, мои сервисные уровни будут иметь реальную логику, например

метод сервисного уровня 

string executeThis= "select c from com.abc.test.User where username =:username";
Map tempMap = new HashMap();
tempMap.put("username","abc");
return callDaoInferface.executeGenericList(executeThis,tempMap);   //get from DI

У тебя это хорошая архитектура

У меня вопрос, подходит ли перенос оператора "select .." из dao в слой обслуживания

Ответы [ 4 ]

3 голосов
/ 06 января 2010

Вы используете интерфейсы в значительной степени так, как это делает Spring, независимо от того, используете ли вы общие DAO. Он включает веб-уровень как часть представления.

Я не в восторге от твоего сервисного кода. Весь смысл интерфейса персистентности состоит в том, чтобы абстрагировать SQL от клиентов, но вы позволили SELECT просочиться в уровень обслуживания. Неправильно, на мой взгляд.

В том, как вы делаете что-то, мало или ничего нет объектно-ориентированного.

Я предполагаю, что "универсальный дао" означает что-то вроде это .

Я сделал это с помощью Spring и Hibernate. Общий интерфейс DAO выглядел так: 

package persistence;

import java.io.Serializable;
import java.util.List;

public interface GenericDao<T, K extends Serializable>
{
    List<T> find();
    T find(K id);
    List<T> find(T example);

    K save(T instance);
    void update(T instance);
    void delete(T instance);
}

Так что, если у меня есть объекты модели User и Book, у меня может быть два DAO, например: 

GenericDao<User, Long> userDao = new GenericDaoImpl<User, Long>(User.class);
GenericDao<Book, String> bookDao = new GenericDaoImpl<Book, String>(Book.class);

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

3 голосов
/ 06 января 2010

Ваша архитектура совсем немного.

Вы хотите, чтобы интерфейс dao абстрагировал краткие взаимодействия БД, или, другими словами, вы могли бы реализовать контракт на доступ к данным с различными реализациями, такими как JPA, Hibernate, Oracle, JDBC и т. Д. Ваши запросы должны находиться в реализации и вы должны изучить именованные запросы, которые, как я знаю, существуют в Hibernate и JPA. Запросы могут различаться в зависимости от реализации, например, специфические нюансы БД (например, «предел» MySQL) или HQL (Hibernate Query Language) или SQL.

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

Общий пример DAO Даффи в значительной степени является стандартом, и я бы предложил реализовать вариант этого ... например. UserDaoHibernateImpl extends GenericDao<User, Long>

2 голосов
/ 06 января 2010

Не совсем, нет. Что делает «TempMap»? Это кажется немного странным.

0 голосов
/ 23 апреля 2016

В настоящее время (в 2016 году) вы должны рассмотреть возможность использования Spring Data JPA вместо создания собственного общего DAO.

...