Generic method from client to db in 3-tier-architecture

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.

If you go that route, are you really a 3-tier architecture, or just a 2-tier architecture with a monomolecular transparent "business" layer in the middle?