Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have played a bit with Spring Roo, now I am asking myself what is the Roo suggested way or best practice way to trigger an action after an object update.
Let me explain it with an example:
Assume I want to implement a web based Bug Tracker (I don’t want to do this, it is only an example). A bug tracker, is about Issues. Each Issue has a state (New, Confirmed, Assigned, In Progress, Resolved.), a title and some other fields.
The user has a web form where it can enter and update all fields (state, title, …). When the state of an issue switches from ‘In Progress’ to ‘Resolved’, the system should send an email to all persons that are interested in the bug (How this list of interested persons is maintained, is out of scope for this problem).
The problem that I have is: How to trigger the email sending process when the state is changed (in a Roo application)? Because there are several problems:
How to determine if the issue state is changed?
We need to make sure, that the message send after the issue is complete updated (for example it would not work, to put the trigger in the setState() method of the Issue, because it is not guaranteed that the other values from the form (title…) are updated before the state is changed.
The mail must only be sended if the form was valid and the Issue is likely to be saved (I do not facing the problem that the transaction cannot be committed – this will be another problem)
Does anybody have a good, testable (unit tests) and maintainable solution? Maintainable means especially that the code to handle this should not be placed in the controller, because it will be used in several controllers and someday somebody will implement an new controller and he will likely forget to handle this email concern.
You can use the #PostUpdate annotation, a JPA life cycle callback listener.
class Issue{
#PostUpdate
protected void onPostUpdate(){
//This method wil run after the update
if(this.state == Resolved){
//...
}
}
Here is more information about the available callbacks.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last month.
Improve this question
I have a mail sender method in my Spring Boot app and when I defining related endpoint in the Controller, I could not be sure what is the most proper request for that.
As I do not pass any parameter and the method does not return any content, I am not sure POST or GET is suitable for this. So, which request should I use?
You need to think of the intention behind the request. Since it is a MAIL request, you are intending to perform some action with this. Hence it would be advisable to use the POST method.
Here is a reference to the existing methods:
GET : The GET method requests a representation of the specified resource. Requests using GET should only retrieve data.
POST : The POST method submits an entity to the specified resource, often causing a change in state or side effects on the server.
Here is the Link for the MDN docs for this.
When you think about the future, there might be some data that you need to send for MAIL which you might not need now, hence using POST makes most sense.
Premised that the choice depends on your personal opinion and habit as developer, and on the specific purpose of your application.
However, in your specific case, I would follow the below logic:
Request is about "retrieving" email -> GET method is better
Request is about "sending" email -> POST method is better
So the logic is the following: as long as I ask the server to only "retrieve" information and I am not going to send any information to the server (i.e: coming from a form), i will always use GET.
On the other hand, when you also need to pass info to the server and it needs to apply some logic/operation, which might also affect some database, in that case the POST method works better.
Hope that answer your questions. Feel free to add more details, I will strive to help you further.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
First of all, this is what I mean by good practice :
code that is easy to maintain / fix
code that can be scaled
an architecture that is not going to cause security issues
With this out of the way, here is my problem :
I have a User class, currently it extends the UserDetails and has additional data attached to it not relevant to security ( for example purposes, let's say I added a user description / a profile page and data ). It works well and I can log in using it.
I, however, have seen tutorials and colleagues separate the data from the user details. They have a MyUserDetails class that only does the bare bones and encapsulates a User class that is used as a data container and nothing more.
Here is a good example of what I mean ( user related classes are roughly
in the middle )
Currently my implementation "works" but I am unsure if it's good practice and am unsure if I should separate the elements contained in my own user class as I don't know if it's any better.
Any help is most appreciated.
If by UserDetails you mean org.springframework.security.core.userdetails.UserDetails class - then it's definitely good idea to separate it from your application model. Single responsibility - one of key stones of good software architecture.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
In order to understand the following question you need to know that I'm a complete novice in the whole Spring Boot ecosystem, as well as, the architectural philosophy behind it.
Task
The app I'm developing with Spring Boot requires, on a business level, some data which are simple collections stored in Firestore. Now, the user when inputting some parameters on the front end (the REQUEST method) and asking for the execution of a certain algorithm on the back-end will trigger the following:
1. The business logic part of the app is going to retrieve some data from the database based on the user input.
2. It's going to process this data and create a RESPONSE based on the retrieved data and a number of other user input.
The problem
So, I'm not really sure if I should be even bothering with creating a service connection for the database since the only one accessing it will be the business logic layer. The database will primarily be build for reads only while at the same time I want to leave open the possibility of later creating a system for auto-updating it (again, only from the back-end, no user interaction/input). Also, what I'm possibly forgetting is the support for multiple connections. Each user may trigger the main algorithm to run utilizing a different set of data retrieved from the database. In that vein, while I would love to leverage the capabilities of Firestore, is the use of it justified in the sense of the data being static for the time being?
You should strive to keep the business logic as pure as possible from implementation choices. Ideally your business logic should not talk to network, file systems or databases. It should be just the pure, refined business logic.
You will then have outer layers that abstract as much as possible these external dependencies. In the case of database, usually you'd have a persistence layer of sorts, which is responsible for accessing directly the database.
For instance, lets say the business logic needs a list of clients sorted by last name. From the business perspective, they're calling a method fetchClientsSortedByLastName() and what that method does is a black box. If at a later moment you decide to switch from Firestore to Postgres or Mysql, you only need to change the persistence method. The business logic will remain exactly the same.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
While working on a Java web application I was wondering if my model layer was written as it should be. For instance, let's say we have a table USER in our SQL database which consists of 15 columns. Now, when we SELECT all of the columns with SQL we map it to a Java class, serialize via JSON and send it via network to some View and show it on screen.
In a second scenario, we want to select only 2 columns on screen so we do SELECT c1,c2 FROM USER. Thats where my question comes in... am I supposed to map those columns to a same Java model class? Or should i create a new mapper and class to fit it? Both of the approaches seem to have drawbacks, separate class for each query is more work, but it makes sure you always know what data it contains, rather than checking for nulls or working with optionals, also it prevents you from mapping columns you actually don't need.
What is your opinion? Thanks a lot!
Technically you could reuse the same User class for full 15-attribute as well as partial 2-attribute entity. But that will come with a price. Every time you'll see an instance of User class in the code your will have to think if it's the full entity or the partial? Which fields may or may not be null? This will make it much harder to reason about code.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
In several occasionS people claims something was 'idempotent' because it wasn't stateful in-memory, even though its consumer effect was recording transactions.
If reading capabilities don't have to be idempotent, getNextIterator() is a reading capability that isn't idempotent as it would increment the iterator. A banking request for a balance wouldn't be idempotent as the request would create an audit log. The returned result might be the same for two subsequent calls (if not changes have happened) but the log entry would be different.
Saying that "logs were created means it isn't stateless" is absurd. Is a call to the server that does nothing "stateful" because a tiny amount of power was used and so your power bill for the month will be a tiny bit higher than it would have been if the call had not been made? No.
Statefulness includes all aspects that matter to the transaction (in-memory, persistent storage, calls to other services, etc). "Idempotent" means that the call may be retried without ill side effects.
Your example of ticking a counter may still be considered idempotent if it doesn't change the business effect of the call or its response to the caller.
Changes internal to the call, that doesn't have any real impact to the business process concerned and that aren't exposed to the caller, are irrelevant to the caller.