Updating OTHER application data on crud operations

[Phillip Stack]

I am trying to learn Java Spring framework. I have been following some books and guides however they are all the standard ToDo ( HelloWorld ) type applications.

One topic that has commonly been untouched in the guides I have been following is how to update other system records upon the execution of crud operations of an entirely different (however usually related) record.

Here is a contrived example.

I have an object ToDo which is persisted in the database. I also have another object ToDoDailyReport which is persisted in the database ( ignore the fact that this could probably be calculated on the fly ).

If I execute any crud operation on a ToDo I would like to update the ToDoDailyReport

I am using spring-boot-starter-data-rest and creating CrudRepositories annotating them with @RepositoryRestResource similar to this example ( https://spring.io/guides/gs/accessing-data-rest/ )

I imagine I could create a bunch of custom controllers using @RestController and implement whatever behaviour I want however I like the idea of leaving their CrudRepositories as is and simply executing a function before or after the crud operation is fired. I have seen discussion of AOP and AspectJ however I am not sure if these approaches are meant for my use case or what approach I should be implementing and how I would fire a AOP advice before or after the crud operation.

My concern with custom controllers is that lets say coming back to my example I want to update the ToDoDailyReport every time a CRUD operation is executed on a  ToDo. If I implement this on a custom controller then I would have to repeat this code for any other custom controller which executes a CRUD operation on a ToDo.

Any advice or direction would be appreciated.

[Peter Rooke]

Not sure, but I think this may help Spring Transaction Management .  

update other system records upon the execution of crud operations of an entirely different (however usually related) record

- Maybe global transactions - but this increases the complexity of the system and decreases the performance.  The underlying resource (database, JMS) has to be able support these types of transactions.

[Tim Nachreiner]

I'm assuming you have an architecture like this: TodoController ==> TodoService ==> TodoDao.
If so, TodoController should handle all CRUD operations on your Todo entity.  Why would you have another controller that performs CRUD operations on the Todo entity?

If you DID have another controller that performed CRUD operations on the Todo entity, that controller could still use the TodoService and TodoDao layers; eliminating the need for duplicate code.

I get the feeling you are looking for a 'Spring-based' solution to your problem in order to learn Spring, but based on your requirements, a database trigger on the Todo table may be more appropriate.

[Tim Holloway]

Welcome to the JavaRanch, Phillip!

Actually, I do the CRUD in the DAOs. But that's basically all that my DAOs do is CRUD and finders on either a single table or a parent/child table set. It's the next layer up (service level) where I do anything involving more than one table. My DAOs are only used by service logic and never by any of the higher layers. The service layer methods are database transactional.

Normally if I have to do side logic, it would either be in the service layer, although if it's non-database logic, I might have a business layer on top of that. Properly speaking, a Controller should avoid business logic, since its purpose in the Model/View/Controller paradigm is to keep data in sync between Model and View.

[Phillip Stack]

Thanks for your responses everyone. I am pretty new to this and so I will need to review these Application Layers you have been referring to. They have been referred to in the books I have been following however they seemed to have been referring to them semantically and never made it clear of the real purpose and expected role of each layer in the application. This will be a good exercise for me as I have really been enjoying my work with Spring so far. It seems to have the structure I am looking for and it is just a matter of learning at this point.

In response to your comment Tim Nachreiner the spring component I mentioned "spring-boot-starter-data-rest" actually creates a bunch of endpoints for you and automatically handles crud operations. So while I agree with you that if I had created a controller with logic controlling each CRUD operation it would be silly to create another controller with another endpoint with the purpose of manipulating the same object.

I did find something that I think is what I have been looking for although I still intend to review all of your suggestions. the documentation for spring-data-rest https://docs.spring.io/spring-data/rest/docs/current/reference/html/#events describes a bunch of events which are fired off surrounding CRUD operations and I think this is what I am looking for. Please feel free to comment if you think that this is me going down the wrong path.

Because ( from my limited understanding ) in sprint-data-rest I am not actually really controlling the CRUD logic itself I can create a listener for the appropriate event ( from the link above ) and then upon the event firing on my ToDo object I could update my ToDoDailyReport.

Or maybe this will all be more clear to me after reviewing the Application Layers

Thanks again everyone, really appreciate you holding my hand here. It has been difficult to get insight into this for me.

[Tim Holloway]

One problem with application layers is that there's no formal consensus of what they should do, how many of them there should be or what their names should be. So different sources will give you different organizations. I've described one that works well for me, but it's not the only way to do things. And, in fact, depending on the app, I may diverge from my standards.

[Phillip Stack]

Regarding the lack of rigid policies on Application Layers I can't say that is surprising. At the end of the day what works is really what is important in my mind and I certainly agree that the "Lab" and the "Real World" are almost never the same. Thanks however your opinion is still really helpful!

[Tim Holloway]

Actually, it's a bit vexing. Design patterns are formally defined and named, why can't we have reasonable conventions on layers? In fact, I'd argue that the various common layers themselves would be design patterns, although it's arguable that at least some of them are specific types of implementations of existing design patterns. Where's the Gang of 4 when you need them?

Eh. I've long since despaired of finding logic in computers, politics or economics.