This discussion is archived
1 Reply Latest reply: Nov 17, 2010 1:54 PM by jschellSomeoneStoleMyAlias RSS

Separation of logic/model/data

814992 Newbie
Currently Being Moderated
I'm writing myself a sample application to practice various things like using Spring and getting into the good practive of separating business logic from model code and from persistance etc. As part of the second intention, I've written a set of Data Access interfaces that I will program the rest of the application code against which can then be implmented against any type of persistance, so that the business logic etc of the program have no knowledge of, or dependance on, the type of persistance used to store data in.

However, for testing I've started developing an XML implementation of the persistance interfaces but in doing so I've realised I don't really know where to draw the line between what is business logic and what should be treated purely as a persistance concern. I suppose there isn't really a definite answer to questions like this but I'd appreciate any opinions from more experienced users. The particular problem I'm stumped by is in resolving references between objects/records. For example, I have a Bluray object that contains information about a Bluray disc, including details about actors in the film but those actors details are actually represented as a Person object. When I come to storing the information, I plan to store Bluray details in on place (table, file, wherever) and Person details in another. This leads to two similar issues, when saving the information, the Bluray DAO will save the references to actors by storing the id of their Person records, and on loading the Bluray DAO needs to be able to resolve Person ids into Person objects.

What I'm not sure of is whether allocating and resolving ids should be the concern of the DAO layer or not. At the moment, when the Bluray DAO is passed a Bluray object to store, it has to pull all the associated Person objects out of the Bluray and use the Person DAO to make sure records are created or update for those Person objects so that there are definitely Person record ids available to store in the Bluray record. This seems quite messy to me, so I'm wondering whether the Bluray DAO should simply assume that the Person objects will definitely have a record id set in them when it comes to store a Bluray and leave it up to the business code that will be calling the DAOs to make sure that DAOs are invoked in the right order to make sure that Person records are created and ids assigned before any other Objects that will need to refer to them by id come to be stored.

Sorry, that's probably not very clear but if anyone can make sense of it and has an opinion as to what the better approach would be, I appreciate some input.
  • 1. Re: Separation of logic/model/data
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    user4853528 wrote:
    I don't really know where to draw the line between what is business logic and what should be treated purely as a persistance concern.
    It is unlikely to be absolute.

    For instance if a "user name" is required then I might have multiple tests at different levels including in the database schema (constraint) to insure that it always exists.
    What I'm not sure of is whether allocating and resolving ids should be the concern of the DAO layer or not.
    For starters you need to define the object data relationships.

    Obviously actors do not own discs and discs do not own actors.
    Thus you have a link between them and not ownership.
    But you might wish to preclude deleting actors that are referenced by a disc. This can be a database constraint.
    At the moment, when the Bluray DAO is passed a Bluray object to store, it has to pull all the associated Person objects out of the Bluray and use the Person DAO to make sure records are created or update for those Person objects so that there are definitely Person record ids available to store in the Bluray record.
    No it doesn't. When you pull a disc you do not have to pull the actors. You might choose to do it but it is not required.

    Consider the user experience. If I am looking for all of the discs with actor A in them then then all I want is a list of discs. I don't want the actors. But if I click on the list to bring up a disc view then there could be a button on that view that lets me pull the actors. When that button is hit then I get the actors.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points