Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Should a business application rely on a generic method called “saveOrUpdate” from the remote client to the hibernate persistence layer?
Background: Our architect argues, that if the amount of use cases in the application are too many or not really determinable, it is ok to go generic over all. As you suggest I am not with him. How are you?
If you’re doing that, you’re migrating your business logic into the client, plain and simple. That’s not necessarily a bad thing; look at the HATEOAS requirement of REST, for example, for a situation where that’s appropriate. However, if you’re trying to do this, you’re breaking the paradigm that the server must be stateless; if the client specifies the “
saveOrUpdate“, then you’re making the assumption that the server is maintaining state beyond the current session, which is architecturally a problem if you’re ever going to want to scale your servers horizontally. Essentially, if you’re driving state from the client properly (as in a HATEOAS situation), your saves will occur as the requests are made, and you won’t need a “saveOrUpdate“; if you really need that from your client, it’s an indication that you’ve improperly migrated your business logic to the client.