11

Scenario:

  • Stack: Java, Spring, Hibernate.
  • Model: Client-Server Application.
  • Pattern: Model-View-Controller (MVC).

The Service Layer classes has three behaviors:

  1. Some services have the business rule within the methods and delegate the persistence to the application. Like:

    EntityManager.save(entity);

  2. Some services simply call a database function (passing parameters) Like:

    CallableStatement cls = con.prepareCall("{call databaseFunction(args)}");

  3. Some services have methods with both behaviors.

My questions:

  1. Is there any problem in having application services call - directly - database functions? Is not this considered bad practice? What would be an architecture model applicable to a project like this?
  2. Is there any problem in having the behavior mix in the same service? Such as transactions and consistency?
  3. In the case of maintenance, does this encapsulation make it obscure to the developer that he should also change the functions in the database? How to avoid this?
  4. Does this scenario happen in other applications around the world or was it just an architectural error?
Improve this question
2

2 Answers 2

Reset to default
7

Is there any problem in having application services call - directly - database functions? Is not this considered bad practice?

I think there is. You are placing a knowledge about the database internals to the application service. Changing database in any way (changing storage engine or even renaming a field or creating index) might require you to change application service and that violates SRP.

What would be an architecture model applicable to a project like this?

See comment below.

Is there any problem in having the behavior mix in the same service? Such as transactions and consistency?

I do not believe there is a technical problem, but there is a logical one. You just mix two approaches in the application making it vague, less structured, hard to adapt to changes. See comments above about violating SRP also.

In the case of maintenance, does this encapsulation make it obscure to the developer that he should also change the functions in the database?

Sure it does.

How to avoid this?

Place methods and functions, that directly work with database into a separate level of abstraction (be it a DAO layer or a simple repository pattern - depends on the complexity of your application)

Does this scenario happen in other applications around the world or was it just an architectural error?

I think in our world everything happens ;)

Improve this answer
4
  • If I understand correctly, there may be a technical issue in that if updates are happening in functions/stored-procs and also through a ORM, the states of a given transaction is very difficult to reason about. While the application might work in it's current state, a small change could cascade into some really big problems. My experience with Hibernate is that if you don't let it manage the entire set of tables it works with, you will have a lot of annoying issues.
    – JimmyJames
    Commented Dec 7, 2016 at 15:16
  • nice and concise answer. SRP was the first thing that came to my mind when i first looked at the code. Some co-workers say that the method does not violate SRP due to the fact that it only call the database function. But some of those functions do selects, inserts and updates. So it does or not violate SRP? (maybe this itself is another question to discuss separatedly?)
    – linuxunil
    Commented Dec 7, 2016 at 16:04
  • 1
    +1 for that line I think in our world everything happens ;)
    – linuxunil
    Commented Dec 7, 2016 at 16:06
  • @linuxunil SRP should be respected on all levels of architecture. In my case I meant SRP at the level of the service, not at the method level. @ JimmyJames Yep. Most of the ORMs do not work well with the stored procedures. But sometimes stored proces are necessary.
    – Vladislav Rastrusny
    Commented Dec 8, 2016 at 8:00
3

According to what you said there's a service layer so the architectural pattern that seems fit is Layered Architecture. Further reference

Yeah it is usually a bad practice to do direct database calls on the other than a data access layer, that way the business layer only access an abstraction of the database.

As for the mixing behaviors, using some design pattern as the DAO pattern or Repository pattern could help to delegate that responsibilities thus improving that code.

Some of the advantages of using a design pattern and a ORM is the readability of your code the encapsulation of the responsibilities so if your database access changes your business layer should not change much.

Improve this answer
3
  • Not sure why this was down-voted. This answer recommends separating code that deals with different concerns. Feels like a principal of programming here... not sure what it is... Man. If only I could think of the name. +1 BTW
    – Greg Burghardt
    Commented Dec 7, 2016 at 15:28
  • Isn't it one of the solid principles?
    – J. Pichardo
    Commented Dec 7, 2016 at 15:30
  • 3
    No. The "S" in SOLID is the Single Responsibility Principal (SRP). But Separation of Concerns, which you are recommending, is a valid reason for separating service logic from data access logic. The other answer by Vladislav mentions the Single Responsibility Principal. Frankly, The SRP and Separation of Concerns go together well, like wine and cheese.
    – Greg Burghardt
    Commented Dec 7, 2016 at 15:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.