Service-Layer werden DB-Technologie in einer Feder Anwendung gebunden

Question

Meine Frage ist: Ist Ihr Service-Layer verwenden, um tecnology Sie gebunden

Zum Beispiel, wenn Sie Hibernate verwenden, setzen Sie sich in Ihrem Service-Layer einige HQL-Abfragen oder Kriterien-Abfragen, die nur Funktionen Ruhezustand oder Sie rufen einfach DAO (und dao hat Hibernate Implementierung und vielleicht jdbc Implementierung etc ..) ?

Ich habe einige Probleme eine efficent geschichtete Architektur für meine Software zu bauen.

Bearbeiten Dies ist ein einfacher Service ... Ich denke, es ist ein Service ... ohne zu tecnlogy gebunden i mit (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 ...
    }
}

Das ist ein Dienst mit Verwendung Dao Umsetzung

@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 ...
    }
}

Weicht diesen beide Ansatz ist richtig?

---

EDIT2

Also, um zusammenzufassen, was ich verstanden:

// 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
}

Es tut uns dieser Wand aus Text, kann vielleicht nützlich sein für andere, die ich hoffe, im in die richtige Richtung gehen? Mein Service-Layer benötigte eine Schnittstelle? Ist alles corectly lagert? Ich brauche eine Steuerschicht zu?

Danke.

Answer 1

Mein Vorschlag:

für größere Projekte, verwenden Sie eine spezielle, Schnittstelle basiert DAO Schicht. Sie nicht Ihr Service-Layer-Know nichts über die zugrunde liegende Persistenztechnologie lassen. Verwenden Hibernate / JPA / JDBC / JDO / was auch immer nur in der DAO Schicht.

für kleinere Projekte kann es in Ordnung sein, nur eine Dienstschicht zu haben (vor allem angesichts der Tatsache, dass beide Hibernate Session und JPA EntityManager entlarven die meisten Standard-DAO Verhalten aus der Box.

Faustregel: Wenn Sie einen Technologiewechsel sind, stellen Sie sicher, dass Sie nur noch eine Schicht Ihrer Anwendung ändern

Update: ist hier eine Probe DAO-Schnittstelle. Ihre Service-Schicht würde nur Code gegen diese Schnittstelle und die Implementierung würde tun, um die Sitzung / EntityManager / jdbc Anrufe ohne den Service-Layer, um zu wissen.

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

Der Schlüssel:. In Ihrem Service-Layer geben Sie Ihre Abhängigkeiten Interface-basierte, das heißt

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

statt

// 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

Die DAO ist der richtige Ort für eine beliebige Datenbank spezifische Abfrage -. JDBC oder Hibernate in Ihrem Fall

Die Serviceschicht ist für das Angebot eine API für die Verbraucher wie eine Präsentationsschicht oder andere gemeint. Es gäbe keinen Grund, den Service Tier mit Datenbank-Spezifika verschmutzen. Ihr Service-Tier könnte Business-Logik hat, die in Ordnung ist, aber es sollte nicht IMO der zugrunde liegenden DB Umsetzung bewusst sein,