Pattern for Database Class?
hello,
i'm using one instance (singleton) of a class that does all database access via JDBC. the class offers methods to query/update the database, it hides all the sql statements from the business classes. the business classes use the methods from my databaseclass and on instantiation of a business class, one constructor parameter is the database object.
now, my boss says this is bad design, but it would like to proof him wrong. is there a pattern for this kind of architecture so that i can show him a neutral example/design pattern that this is good? (my arguments: the database class manages the database connections, can implement data caching, connection pooling, etc. and is a singleton, because it much more expensive to have a single data access object for each business class that is instantiated each time the business class is instantiated and opens new database connections each time...)
any advice?
Get the book Patterns of Enterprise Application Architecture by Martin Fowler. Itis the best book, that I have read in a long time on patterns and the Enterprise. He talks about Domain Model classes which contain the business logic and then Data Mapper classes which provide access to the database and use load the data into the domain model classes. The only change I would suggest is moving the connection into a Connection Pool class which is a Singleton. Depending on the complex nature of your project, you might want to have a Mapper class for each Domain model class.
ex.Domain Model class -CustomerBean.
Data Mapper - CustomerMapper.
Domain Model class -InventoryBean.
Data MapperInventoryMapper
Connection classConnectionPool (singleton)
Encapsulating access to a database and other persistence services is always a good idea. One approach named a Data Access Object (DAO) is documented in Alur et al: Core J2EE Patterns. You'll find a description at http://java.sun.com/blueprints/corej2eepatterns/. What I don't understand about your design is, that you pass a reference to the database class as a parameter to the constructor. This introduces an unnecessry and unwanted coupling. Getting and setting information is possible simply by ensuring that the database class is within the callers namespace.
Regards
In some sense it actually is bad design.
1. as mentioned in the previous post, you don't need to pass the database object as a parameter. Since it is an singleton the object can get it whenever it needs it.
2. When your system grows you database object will grow as well, it would be a good idea to have a database object for each business class or at least for each group of business class.
All that said ... it of course doesn't mean that the model suggested by your manager is any better.
regards
Spieler
>
> 2. When your system grows you database object will
> grow as well, it would be a good idea to have a
> database object for each business class or at least
> for each group of business class.
>
That's another (important) point. In your current design you're risking that the database class will become bloated, i.e. will assume too many responsibilites. When you've written the first few database classes, you'll presumably be able to factor out some common behaviour.
With multiple database classes, consider using the Factory Pattern (GoF) for creation.
Regards
