This discussion is archived
2 Replies Latest reply: Aug 19, 2011 1:40 PM by jduprez RSS

N-tier and Repository Design

882947 Newbie
Currently Being Moderated
I have a design problem. The application I am assigned to, has a table in a DB which has an operation type (add, update, delete) and the data associated with that operation. A process has to perform the operations (in other DB) specified in that table with the corresponding data. I want to model this using n-tier architecture and the solutions I've found are: 1) Create a method in service layer, which finds all the objects from the table with a Repository and checks with "if" sentences the operation type. For example: If its an ADD, call the Repository method add(Object); 2) Create an Entity which uses strategy pattern with operation type.

1) I dont like the several if sentences, and there is no business logic in the Entity. 2) I dont know how to call the add/delete/update method from the repository in the strategy, unless the entity see the repository (is this good?).

Can someone help me with the right solution please?

Thanks!
  • 1. Re: N-tier and Repository Design
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    Why is this complicated?

    General solution
    1. Read row
    2. Process row
    3. Repeat 1/2 while row remain.
    4. If no rows either sleep (try again after) or exit.

    Last step depends on needs.
    Implementation detail is what do when an error occurs.
    Internals of step 2 depends only on what +"specified in that table with the corresponding data"+ really means.
  • 2. Re: N-tier and Repository Design
    jduprez Pro
    Currently Being Moderated
    Given the extremely non-obvious connection between the topic's title and your description, I assume there is much more to it than the details you give, but based on this description alone:

    First, I understand your question as applying only to what jschell above calls step2 (implement the processing of a row).

    Now, as far as evaluating your options:
    1) Create a method in service layer, which finds all the objects from the table with a Repository and checks with "if" sentences the operation type. For example: If its an ADD, call the Repository method add(Object);
    I dont like the several if sentences
    I don't see why - frankly, if there are really not much more than 3 types of operations, and the list is not likely to change in the future, Strategy is overkill!
    So the second option is only valid if the actual operations are quite different and more numerous than your description. Maybe you tried to oversimplify the description, that's nice of you to spare us, but you may end up with inappropriate advices then.
    and there is no business logic in the Entity.
    So what? You don't have to put BL in Entity classes.
    2) Create an Entity which uses strategy pattern with operation type.
    I dont know how to call the add/delete/update method from the repository in the strategy, unless the entity see the repository (is this good?).
    I don't know, is there a way in JPA to map a given table to several classes of a given hierarchy? Because if not, then the Entity classes would not be the Strategy classes, instead you would have a single Entity class that delegate to an instance of a Strategy class. The problem is then how to select the appropriate strategy? Using if(..)s? :o) Back to it below...

    Moreover, if you follow the Strategy way, why put it at the Entity level instead of in the Service layer?

    Indeed, whether you put the Strategy in the entity or in the service, the point is to instantiate or choose the appropriate Strategy class - without using if :
    - you may use reflection for that (map Operation type to class name, and load Strategy class by this name, instantiate it, provide context, execute).
    - You may traverse a list containing an instance of each Strategy class, and use some filtering ( +if(strategyInstance.appliesto(theOperationType) {...+ ).

    But again, reevaluate whether you need to overdesign elaborate code just to avoid a couple of if statement.

    Regards,

    J.

Legend

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