CODEWITHSUNDEEP
javaspringspring-mvcmodel-view-controllerservice
serhii
serhii

Reputation: 1177

MVC practices. Service within another service

Service1 injects Repository1. Service2 injects Repository2.

Suppose two different scenarios:

1) Some method of Service2 needs to retrieve data from Repository1. Should Service2 inject Service1 or Repository1 when both of them provide respective get() method?

2) Some method of Service1 at it's end should call another method from Service2. Is it a bad practice to inject Service2 to Service1 for such needs? Is it a good practice to use event listen techniques like AOP for such needs?

Upvotes: 10

Views: 7090

Answers (2)

josh26757
josh26757

Reputation: 34

I am not greatly experienced with this problem, but personally I would avoid coupling controllers. My first approach would be trying to create an interface that would fit all models if possible. It would then be possible to create a model that wires multiple models together to access the data you need without adding references to the controller. For instance:

Model1 implements iModel{}
Model2 implements iModel{}

ModelWrapper implements iModel{
    private iModel model1;
    private iModel model2;

    public ModelWrapper(iModel model1, iModel model2)
    {
        this.model1 = model1;
        this.model2 = model2;
    }

    public SomeDataType getSomeValue(){
        SomeObject.param1 = model1.method();
        SomeObject.param2 = model2.method();
        return SomeObject;
    }
}

I am sure there is a better way to approach the number of models passed into the constructor and also a way to search each model for the data you are looking for. If the data is not found a null reference or better a custom error could be thrown. If the implementation is consistent perhaps the wrapper could combine all models and allow access to many custom combinations. At least this way, when requirements change you can simply add an additional wrapper to get what you need without changing the current implementation.

Perhaps a more experienced developer will build on my response to provide you a better implementation, but I hope this helps.

Upvotes: -1

vine
vine

Reputation: 886

There are many factors to consider here when we talked about best practices.

As a good start, try to understand the concept of SOLID principles. Generally, it is good to have multiple classes with very focused roles that calls the other rather than combining all functionalities in one class. High reusability and least code duplication which in turn gives maintainability.

For scenario 1.)

It is perfectly fine to have a service calling another service if that business code defined in the method is the same business functionality needed by the other service. This follows the DRY principle, no redundant codes.

But it is also perfectly fine to just directly call the Dao from a service instead of calling a different service to do that for you if it is just a simple call with no further business logic. Especially if the two services are in the same module anyway, there is no strong reason to make another service a bridge class for an obvious simple single line of code unless you want to abstract it, but in your case, its just a simple get call.

For scenario 2.)

But another thing to consider is modularity and direction of dependency. If each service calls each other, there could be problem in your design, as much as possible avoid circular dependency on different modules because this could lead to spaghetti code, better to extract same code to a different class declared on common module that can be shared by many modules.

Final note, as what Robert Martin says, you won't be able to code at once the cleanest code in one round. Best codes are forged by continuous refactoring and code cleanup. To quote Robert Martin,

The Boy Scouts have a rule: "Always leave the campground cleaner than you found it."

Upvotes: 17

Related Questions