I have a couple of architectural questions. This is rather long winded, I'm afraid so settle in.
1. I'm attempting to write an API for
j2EE that is as flexible and extensible as possible. It uses such design
patterns as Data Access Object, Business Object, Service, etc... oh.. and I'm using
Struts. This question centers around the Integration layer of my application. I've more or lessimplemented an object-relational mapping, with JavaBeans mapping to database tables. There are subsequent Service classes/interfaces, DAO classes and interfaces for each table in the DB (for exampl, there is a User JavaBean class, a UserService class which implements a AppService interface, and a UserDAO which implements a UserDAOImpl interface). My boss is concerned about the proliferation of DAO classes throughout the integration layer as the database continues to grow, thus hindering code maintainability. (Each DAO is a Singleton, so there isn't a problem with object proliferation.) I've told him that the problem with maintainability lies not in the number of classes, but rather with the implementation. In other words, so what if there's a DOA for every table, as long as the interface methods are implemented properly depending on the datasource and the design rules aren't broken? I also told him that simple isn't always better. Simple in terms of fewer class files that is. This is to say that if a particular class represents a particular function/data (e.g. a User that maps to a Users table) then it SHOULD be in its own class following basic design principles or refactoring and division of labor. So, I guess my question here is am I way off base and, if not, is there anything else I can say to justify this "profliferation." If I am off base.. how come?
2. This relates to my first question in terms of extensibility. Say I get this API written before I die and I've written a J2EE app with it. Suddenly I need to add a database table, or worse, a column to an existing table - in short, the data model changes. What's the best way (if any, I'm not sure there is) of making this change with the least amount of pain. The way I'm envisioning the architecture now, making a change to a DB table would require me to change code in, the DAO, the Service, maybe the DAO interface and the JavaBean (which would require changing code in the servlet/action class and/or the
JSP). Adding a table, would have similar ramifications. Is there a recommended practice for accounting for such changes? My gutt reaction, based on what I currently know, is to say... "yeah.. well.. you wanna make sure the data model DOESN'T change. Otherwise THAT'S the cost." Anyone have any advice?
THANKS!
[ November 24, 2003: Message edited by: Brian R. Wainwright ]
