Win a copy of Micro Frontends in Action this week in the Server-Side JavaScript and NodeJS forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Liutauras Vilda
  • Paul Clapham
  • Bear Bibeault
  • Jeanne Boyarsky
  • Ron McLeod
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Jj Roberts
  • Stephan van Hulst
  • Carey Brown
  • salvin francis
  • Scott Selikoff
  • fred rosenberger

Architecture/Pattern Questions

Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
[ November 24, 2003: Message edited by: Brian R. Wainwright ]
Create symphonies in seed and soil. For this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic