• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

comments on simple design to access database

 
Ranch Hand
Posts: 3852
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A class ConnectionFactory has a method getConnection(), which uses DataSource to get the connection (so connection pool will come in handy automatically, right?).

All model classes will have a handle of ConnectionFactory (aggregation or 'has a' relationship) to get the connection and then usual database code depends on the business.

Hope the idea is clear.

Thanks.

[ September 19, 2007: Message edited by: ankur rathi ]
[ September 19, 2007: Message edited by: ankur rathi ]
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is one style that has "business objects" able to store themselves. So your "unit of work" controller might say:

Customer class might have a method:

Note that the Customer is not bound to a particular persistor. The factory might look up the Customer class in configuration and get a database persistor or a JMS persistor or something else. That method is so generic it could be in a base class PersistableBusinessObject or something.

Another style is to have persistence separate from the domain objects. Now the controller might say:

Hmmm, the factory and ht actual persistor didn't change one bit. The business object now knows nothing about persistors at all, so we don't need that clumsy base class. I lean toward this style.

Read up on how serious frameworks do this, say Spring and Hibernate. They'll be a lot more sophisticated than my quick examples. And using one would probably be a lot better choice than writing your own.
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Seems like it's a fairly common way to grok the concept of "Separation of Concerns". I also started with designs that had business objects know how to save themselves. As I gained more experience, I moved to the latter approach of making business objects not care about how they are saved/retrieved. Hmmm...You might even say that one design rule of thumb then is to "Seek first to separate concerns before encapsulating behavior."
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Junilu Lacar:
Hmmm...You might even say that one design rule of thumb then is to "Seek first to separate concerns before encapsulating behavior."



One always has to be careful not to over-generalize because there is no "one size fits all" solution. Java Enterprise reference implementations are full of DAOs (Table Data Gateway), yet really complex applications can benefit from moving to a Domain Model with a Repository using a Data Mapper.

Meanwhile the applications that are being implemented in Ruby on Rails make good use of (generated)
Active Records. In some cases even an active record can be overkill and a Table Module is sufficient.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Peer Reynders:
One always has to be careful not to over-generalize because there is no "one size fits all" solution.



Absolutely. As with anything, you must always consider the context in which you are employing a solution. Where an approach is appropriate in one context, an opposite approach may be best in another. Take for example the Replace Delegation With Inheritance refactoring vs. the Replace Inheritance with Delegation refactoring

I find it interesting that perhaps due to the automagic nature of implementations of ActiveRecord in frameworks like Ruby on Rails, the mixing of concerns is not really that much of a design issue anymore since the framework shields the developer from any negative effects of the close coupling of the domain and the database.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To the original poster, if you're still around, I don't think any of the linked designs - except perhaps ActiveRecord - suggest "All model classes will have a handle of ConnectionFactory (aggregation or 'has a' relationship) to get the connection and then usual database code depends on the business." but instead move the interaction with the database out of the model to another layer.

My point was to think about whether you want Model classes to even know about the persistence classes. There are plenty of reasons to answer either yes or no depending on your needs. Look over the links in the thread and tell us what you think looks appropriate.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic