Home/ Questions/Q 7052681
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T03:24:47+00:00

I’m doing some maintenance/evolution on a multi-layered spring 3.0 project. The client is a

  • 0

I’m doing some maintenance/evolution on a multi-layered spring 3.0 project. The client is a heavy RCP application invoking some spring beans methods from the service layer (Managers) on a RMI based server.
I have several huge method in the Managers, some of them are doing more than 250 lines.Here is an example : (I’ve omitted code for clarity)

    @Transactional(readOnly = false, propagation = Propagation.REQUIRED)
 public Declaration saveOrUpdateOrDelete(Declaration decla, List<Declaration> toDeleteList ...){

     if (decla.isNew()){

        // create from scratch and apply business rules for a creation

        manager1.compute(decla);
        dao1.save(decla);
        ...

      }else if (decla.isCopy() {

         // Copy from an other Declaration and apply business rules for a copy
         ...

       }else {

         // update Declaration
        ...
       }
     if (toDeleteList!=null){

       // Delete declarations and apply business rules for a mass delete
        ...
       }

The first 3 branches are mutually exclusive and represent a unit of work. The last branch (delete) can happen simultaneously with other branches.

Isn’t it better to divide this method in something more ‘CRUDy’ for the sake of clarity and maintainability ? I’ve been thinking of dividing this behemoth into other manager methods like :

public Declaration create(Declaration decla ...){...

public Declaration update(Declaration decla ...){...

public Declaration copyFrom(Declaration decla ...){...

public void delete(List<Declaration> declaList ...){...

But my colleagues say it will transfer complexity and business rules to the client that I will loose the benefit of atomicity etc.. Who is right here ?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The decision what the updateOrCreateOrWhatever really does is made in the client anyway as it has to set the corresponding field in Declaration object.

    The client could equally well just call the apropriate method.

    That way code is definitely more manageable and testable (less branches to care about).

    The only argument for maintaining it as is is the network round-trips mentioned by @Pangea. I think this could be handled by custom dispatcher class. IMO it doesn’t form a part of business logic, and as such shouldn’t be taken care of in service layer.

    Another thing to take into consideration is transaction logic. Do create/update and deletes have to happen in the same transaction? Can both decla and toDelete be not null at the same time?

    • 0