It feels less object oriented Smile But persistance is only an aspect of your system, just like logging, security etc. If you mix all those aspects of your system in a single class, your class will get bloated. Sometimes it is better not to rely in inheritance but on other techniques to seperate those aspects (concerns).
The advantage of separation:
-single place where all the db code is (this makes it a cleaner design)
-easier to replace the whole dao implementation with something else.
-less long classes.
-you are limited to the functionality with your approach the classes have to offer. If you seperate those aspects and only let them depend on the domain model, it is easy to add new peaces of functionality (new aspects) to your system. [/code]
Alright I guess the separation makes a lot of sense conceptually. My thing though is from a practical perspective when persisting to a db is such an obvious and central requiirement of an application it seems you are separating the inevitable.
But If I may- I have one more question about this whole separation dao thing. Undoubtable an application will have domain objects which contain other domain objects, For instance if you have a Customer object it might contain a list of Order objects. Now in this case your db would have a customer table and an order table with a joiner linking them. When you work with the Customer Object you would want to be able to get all the customer orders. I would want to have a method getOrders in the Customer object like so:
Code:
customer.getOrders();
public class Customer
{
private int id;
Collection getOrders()
{
OrderDAO orderDAO = OrderDAO.getInstance();
return orderDAO.getOrdersByCustomerId(this.id);
}
Is this appropriate? I ask because it would entail the customer having access to the OrderDAO object.
Or take another case - a Customer has an Address. Where in the db you have a Customer table that has an address_id on it and then an Address table.
Code:
public class Customer
{
private int id;
private Address address;
private Address getAddress()
{
returnaddress;
}
private setAddress(Address address)
{
returnaddress;
}
}
In this case the customer would have to load the address in the CustomerDAO:
Code:
public class CustomerDAOImpl implements CustomerDAO
{
Customer getCustomer(int id)
{
Customer returnValue = new Customer();
int customerAddressId ;
//some kind of sql to get the customer values and the address id from the customer table
AddressDAO addressDAO = AddressDAOImpl.getInstance();
returnValue.setAddress(addressDAO.getAddress(customerAddressId);
return returnValue;
}
}
So in this case the CustomerDAO has to have access to the AddressDAO is that the right way to do this? Or do you get access to the AddressDAO in the actual customer class like so:
Code:
public class Customer
{
private int id;
private int addressId;
private Address getAddress()
{
AddressDAO addressDAO = AddressDAOImpl.getInstance();
return addressDAO.getAddress(addressId);
}
private setAddress(Address address)
{
addressId = address.getId();
}
}
planning major migration to spring
Reply With Quote
Originally Posted by katentim
But persistance is only an aspect of your system, just like logging, security etc. If you mix all those aspects of your system in a single class, your class will get bloated. Sometimes it is better not to rely in inheritance but on other techniques to seperate those aspects (concerns).
