Сервисный слой связан с тентологией БД в пружинном приложении

Question

Мой вопрос: Ваш сервисный слой, связанный с Tecnology, который вы используете?

Например, если вы используете Hibernate, вы помещаете в свой сервисный слой некоторые HQL-запросы или критерии-запросы, которые являются только Hibernate функциями или вы называете просто DAO (и DAO Hibernate, и, возможно, реализация JDBC и т. Д.)?

У меня возникли проблемы с построением эффективной слоистой архитектуры для моего программного обеспечения.

РЕДАКТИРОВАТЬЭто простой сервис ... Я думаю, что это услуга ... не привязанная к Tecnlogy I использую (Hibernate)

@Repository
public class PersonHibernateDAO implements PersonDAO {

    @Autowired
    SessionFactory sessionFactory;

    ... dao crud operations(implementation of PersonDAO interface) using sessionfactory ...

    //and some hibernate features methods
    public Person findByCriteria(Criterion criterion){
        // code
    }
}

@Service
public class PersonService {

    @Autowired
    private PersonDAO personDao;

    @Autowired
    private AccessDAO accessDao;

    @Transactional
    public boolean hasPermission(String username, String accessCode){
        Person p=personDao.findByUsername(username);
        Access a=accessDao.findByCode(accessCode);
        ... etc ...
    }
}

И это услуга с использованием реализации DAO

@Service
public class PersonService {

    @Autowired
    private PersonDAO personDao;

    @Autowired
    private AccessDAO accessDao;

    @Transactional
    public boolean hasPermission(String username, String password){
        Person p=((PersonHibernateDao)personDao).findByCriteria(Restrictions.eq("username", username);
        ... etc ...
    }
}

Вича этих двух подходов правильно?

---

Редактировать2.

Итак, чтобы обобщить то, что я понял:

// BASE DAO INTERFACE
public interface DAOInterface<EntityClass, IDType extends Serializable> {
    EntityClass get(IDType id);
    EntityClass findById(IDType id);
    EntityClass save(EntityClass entity);
    EntityClass update(EntityClass entity);
    void delete(EntityClass entity);
}

// AN HIBERNATE IMPLEMENTATION
public abstract class HibernateDAO<EntityClass, IDType extends Serializable> implements DAOInterface<EntityClass, IDType> {

    @Autowired
    private SessionFactory sessionFactory;

    public void setSessionFactory(SessionFactory sessionFactory){
        this.sessionFactory=sessionFactory;
    }

    public void getSessionFactory(){
        return this.sessionFactory;
    }

    // Implements all DAOInterface method using sessionFactory

}

// PERSON DAO INTERFACE
public interface PersonDAO extends DAOInterface<Person, Long>{

    Person findByName(String name, String surname);
    List<Person> getInAgeRange(int year1, int year2);
}

// PERSON HIBERNATE DAO IMPLEMENTATION
public PersonHDAO extends HibernateDAO<Person, Long> implements PersonDAO{

    // Implements the methods of PersonDAO interface using sessionFactory
}

@Service
public class PersonService {

    //spring inject the correct DAO by its xml config(in this case PersonHDAO
    @Autowired
    private PersonDAO personDAO; 

    // spring manage the transaction
    @Transactional
    public List<Person> getInAgeRange(int year1, int year2){
        return personDAO.getInAgeRange(year1, year2);
    }

}

// NOW... HOW USE IT
//let's assume i have a button, pressing it a table will be populated with all persons in age range
private void actionPerfom(ActionEvent e){
    List<Person> list=personService.getInAgeRange(age1Spinner.getValue(), age2Spinner.getValue());
    //Load a table with list
}

Извините за эту стену текста, может быть, может быть полезен для других, я надеюсь, я иду в правильном направлении? Мой сервисный слой нужен интерфейс? Все ли Cerecty слоистые? Мне нужен контрольный слой тоже?

Спасибо.

Answer 1

Мое предложение:

Для более крупных проектов используйте выделенный слой DAO на основе интерфейса. Не позволяйте вашему сервисному слою знать что-либо о базовой технологии настойчивости. Используйте Hibernate / JPA / JDBC / JDO / Что бы ни в слое DAO.

Для меньших проектов может быть только в порядке, чтобы иметь только сервисный слой (особенно учитывая тот факт, что оба гибернация Session и JPA EntityManager выдержать самое стандартное поведение DAO из коробки.

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

Обновлять: Вот образец интерфейса DAO. Ваш сервисный слой только для этого интерфейса будет только для этого интерфейса, и реализация будет выполнять вызовы сеанса / EntityManager / JDBC без использования сервисного слоя, необходимого для знания.

public interface CustomerDao extends CommonDao<Customer>{
    Customer getCustomerByEmail(String emailAddress);
    List<Customer> getCustomersWithinAgeRange(int lowerBound, int upperBound);
}

Ключ: в вашем сервисном слое укажите свои зависимости на основе интерфейса, т. Е.

private CustomerDao customerDao;
public void setCustomerDao(CustomerDao customerDao){
    this.customerDao = customerDao;
}

вместо

// this is horrible, it ties the service layer to implementation
// details of the dao layer
private HibernateCustomerDaoImpl customerDao;
public void setCustomerDao(HibernateCustomerDaoImpl customerDao){
    this.customerDao = customerDao;
}

Answer 2

DAO - это место для любой конкретной конкретной базы данных - JDBC или Hibernate в вашем случае.

Сервисный уровень предназначен для предлагает API для потребителей, таких как презентационный уровень или другие. Не было бы никаких причин загрязнять сервисный уровень с помощью конкретной базы данных. Ваш сервисный уровень может иметь деловую логику, которая в порядке, но не следует знать о базовой реализации БД ИМО