Win a copy of TDD for a Shopping Website LiveProject this week in the Testing 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
  • Piet Souris
  • Himai Minh

Application Tiers and Data Access

Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi there,

I am developing an application for university project, and here is the problem I am facing at the moment:

I have a Business Logic application, which acts as a backend system and handles all business logic. This will be used by a web application front end. It will also be queried by another application which is not a web application.

So basically I want my Business Logic application to handle all Data Access and database queries. This means that I won't be able to make use of the datasource features offered by the application server im using for my web application.

Is all the above ok? Does this architecture make sense? and if so, what is the best way to handle DA in my BL application? through connection pools?

Any help would be appreciated.

Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why can't you use an instance of the app server to implement your business logic server?

If that isn't viable, why can't you use an existing persistence framework? See Encapsulating DB Access for strategies and Design of a Persistence Layer for a list of options.

- Scott
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I see several options coming from your own comments and Scott's suggestions. See if I boiled these down the same way you do ...

1) Use a single technique all the time, whether the code is running in the app server or as part of the standalone application. It might be straight JDBC, a framework of your own or an established tool like Spring or Hibernate. As you described it: don't use the features of the app server.

2) Build an abstract interface for data access with one implementation for the app server and another implementation for standalone use. The app-server one could use the server's datasource while the standalone one makes its own JDBC connections.

3) Make the standalone app call through the web server instead of directly calling the persistence package, making your business layer a web service. This is likely overkill; the urge to make every last thing a web service is sometimes just inappropriate. Or it may have value if it makes a "pointy haired boss" say "Ooooo, web services! I've heard of those! I see raises and promotions in your future!" Seriously, it is reuse of a running system rather than reuse of code. Sometimes that's a useful distinction.

Any of those sound worth digging into for more detail?
Did you just should on me? You should read this tiny ad:
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earth
    Bookmark Topic Watch Topic
  • New Topic