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.