• 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

Tying together data access, business and web tiers

 
Ranch Hand
Posts: 146
2
Mac Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'd like some advice on how I should proceed with a small application I am writing. The main purpose is to get to grips with the JEE stack, but I also want to consider good practices. A short problem definition is that I need to be able to keep track of the costs involved in buying, selling and moving house, the outstanding balance of costs and whether they have been paid or not. It is possible that none or more houses could be purchased, sold and moved between in a transaction (the combined act of buying, selling and moving), and over time there could be several transactions. Because it is personal financial data it needs to be kept secure. Anybody should be able to set up a transaction and keep track of the costs involved and be able to keep track of these from anywhere in the world. The method of inputting and viewing information needs to be as simple as possible. A database backed application with a web front end has been decided as the method in which to bring all these elements together.

I have a database with the following schema (? used to show it's a boolean value):

  • user (user_id, email, password, firstname, last name).
  • transaction (transaction_id, name, complete?, user_id).
  • sale (sale_id, name, complete?, transaction_id).
  • purchase (purchase_id, name, complete?, transaction_id).
  • move (move_id, name, complete?, transaction_id).
  • sale_cost (sale_cost_id, name, value, paid?, sale_id).
  • purchase_cost (purchase_cost_id, name, value, paid?, purchase_id).
  • move_cost (move_cost_id, name, value, paid?, move_id).

  • And the following relationships:

  • user 1:N transaction (transaction_user_FK).
  • transaction 1:N sale (sale_transaction_FK).
  • transaction 1:N purchase (purchase_transaction_FK).
  • transaction 1:N move (move_transaction_FK).
  • sale 1:N sale_cost (sale_cost_sale_FK).
  • purchase 1:N purchase_cost (purchase_cost_purchase_FK).
  • move 1:N move_cost )move_cost_move_FK).

  • Other than the basic CRUD operations and validations, which the entities are clearly best placed to do themselves, I'm confused as to where the remainder of my logic should go. For instance, a transaction knows the sum of all it's costs, but it derives these from the various component parts. Thus a sale knows how to sum all of the sale_cost entities related to it, likewise for purchase and move. So in my mind, a request for the balance of costs left to be paid would see transaction ask each of its sale, purchase and move objects to sum all of their costs, and would then sum these and return to the user. Is this logic correctly placed in the respective entities?

    Why then, do I need a business layer? What does it do for me? Or, should the logic for summing all of these bits be placed in the business layer? If I updated the costs entities to have a part payment field, I'd then need to update the business logic tier code too. Keeping it in the entity seems to make sense. It seems that to display something meaningful to the end user, a request must be made to a JSF Bean, to an EJB, to an interface between the entity and the EJB, to the entity, and then back again. Thus having a business tier seems to be counterintuitive. However, I might be missing something, not understanding something, etc.

    Some advice on ways this implementation could be achieved using best practices that will serve well for larger and more complex applications would be very helpful. Any pros and cons of possible implementations would also be appreciated, as would any glaring issues with my schema. Thanks in advance, although I'm sure I'll be posting back and asking more questions in response to answers.
     
    Ashley Bye
    Ranch Hand
    Posts: 146
    2
    Mac Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I have decided to take the Boundary, Controller, Entity approach as discussed here by Adam Bien at JavaOne 2014. The approach certainly seems less complex than trying to pick relevant parts of the Core J2EE Patterns. If my understanding is correct then this seems like a clean and simple approach because:

  • I can package the entire application in a war file for deployment without need for an ear file with the business logic.
  • I have no duplication of effort amongst beans.
  • My project is small, so I can even do away with the controller and just use boundary and entities.


  • I assume, however, that to connect this to a JSF front end I will still need to inject the boundaries into the JSF beans, whether they be request, session, view, etc scoped. Is this correct? The other option is to expose a REST interface instead and use something like AngularJS to build the front end. With this approach, would I communicate with the boundary direct? I'll probably take the former approach since I don't want to start learning another technology at the moment.

    I'd appreciate any thoughts on taking this approach as I don't have enough experience to be able to compare the advantages and disadvantages between different methodologies.
     
    Greenhorn
    Posts: 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    In spring 2015, I published "Architecture Logicielle" in French (translation Software Architecture, ser http://www.jailinux.org for online pdf)
    This is a revised second edition of a book written in 2007.
    This book is driven by a simple example application evolving with an iterating life cycle.
    Starting from a batch application for sending email, it evolved to a graphical user interface to send mass email.
    After this first step a second group of iterations migrates the different parts of the application to a data access, business and user interface tiers.
    I introduced a very small library to enforce this separation.
    But the value of the book is not in this library but in showing how to evolve to such an architecture.
    The 3 tiers architecture is not a static architecture you will learn by studying an existing application.
    Rather you will learn this pattern by developping and migrating a simple application to this constraining model.
    If I find sufficient interested persons in this book, it will be interesting to translating it to English.
    Let me know.
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic