11

I am new to concepts like DAO, DAL and Domain Driven Design. In the end I want to decouple the persistence layer (mysql database) from my business objects and logic in a web application. I liked the DAO concept but I got stuck implementing it when I want to create a Business Object from database that has other entities associated with it (represented by foreign key in the db table).

  1. How are these references (aggregations) handled using DAO pattern? Every online DAO example is simple and shows creation of value-object-like Business Objects only (without referencing other entities or value objects). Is it done using Dependency Injection and if so, where is the dependency created?
  2. By further reading I guess that Repository pattern from DDD gives the possibility to maybe use DAOs behind the scenes and handle object aggregations. As I understand it, it only provides the so called root (Entity with all references loaded or lazy loaded) to the outer world, what seems a good approach to me. Is Repository recommended when using DAO or can DAOs themselves give this functionality by maintaining Persistence Ignorance to the Business Objects.

I am not using an ORM tool and don't want to as I like to explore these basic patterns directly

3

2 Answers 2

4

There are two concerns to deal with - which are orthogonal to each other:

1) The lower end of persistence

This is where you have to deal with Connections,Queries, Resultsets and the like. Typically you use the one or the other framework which gives you a facade-pattern at hand, which abstracts away the dirty stuff away so that you only tell, what you want to know(Resultset from Query) and where the framework could find it (Query and Connection). What you do with the resultset is up to you.

When your paradigm is OOP, there is an additional step involved: assembling the resultset to objects. Either you do it manually or have an object-relational-mapper doing the job for you.

2) The abstraction within your application On top of this low level layer sits the abstraction with which your application deals. There is the DataAccessObject (DAO)-Layer or the Repository-Layer. Both generate Objects for your Application to work with.

Which one you are using has no effect on the answer of your question.

Your question is on the one hand on modeling (»How to handle relationships between objects« Answer: via Composition/Aggregation) and on how to fill the object (and its dependencies) with data.

Is it done using Dependency Injection and if so, where is the dependency created?

This is the way to go. There are two ways:

1) You make the DI explicit and define a constructor. When creating the Object, you are able to create all dependencies first and inject them via constructor or setter injection

2) You use a framework, which does the magic for you. Oftentimes reflection is involved, i.e. there are possibilities within some languages to examine and manipulate objects on the fly. The injection is done transparently for the user by the framework.

This is independend from the DAO/Repository-pattern.

I am not using an ORM tool and don't want to as I like to explore these basic patterns directly

That's a noble approach, but not in every case productive. Most of the time, you want to get stuff done. For educational purposes, you could go down that road. But I would not recommend it.

Look out for a flexible ORM-Framework, which gives you a helping hand when needed without forcing you in one way or the other. Not in every case is the ootB generated query effective. A good framework let's you use SQL when needed and takes only care of the assembling part.

1

This is where ORM (object-relational mapping) comes in handy. There are libraries for many programming languages, that provide this type of programming techniques. E.g. for Java there is Hibernate. Hibernate works with Java annotations. Here's a simple example for a many to one relationship from the official documentation:

@Entity
public class Flight implements Serializable {
    @ManyToOne(cascade={CascadeType.PERSIST, CascadeType.MERGE})
    @JoinColumn(name="COMP_ID")
    public Company getCompany() {
        return company;
    }
    ...
}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.