问题
Specifically, the EIS (database) Tier versus using the Web tier with POJO's and a light framework or the standard business logic tier using EJB's. Also, there may be other options besides these that I'm not aware of. Basically, it's design considerations for business logic with and without EJBs. Guidelines for using one alternative over the other.
This would be in the context of a Java EE application deployed on an app server.
My impression is that there should be some basic guidelines as to how this should be structured in an application and it couldn't be always one over the other, like use the database for performance reasons or always use EJB's, since I worked with applications that have used all three of these structures. I just had never thought about what design guidelines should I use in making the determination?
I'm thinking along lines of:
- If you have database tables with millions of rows in them, look at putting business logic in stored procedures and triggers.
- If you have simple business logic for a an application, look at using POJO's for the business logic.
回答1:
I would try to do the following questions:
- Is there a requirement of high performance ?
- what is the infrastructure ? one server? cluster? cloud ?
- do I have limited memory ?
- the application is going to use/manage thousands of records, or millions, or billions?
- how long will it be live ? 5 years, 20 years?
- how large is the application, how many developers will be working on it ?
- Are the developers familiarized with the technology (i.e. framework)?
I think for large applications with several developers working at sametime and that is planned to be live a long period of time, is a big advantage to use the architecture WEB/EJB/JPA , it generates code highly maintainable and very easy to read. But if the application is going to work with several millions of records , probably is better to think in a technology/framework with better performance.
回答2:
There isn't just one best way to approach this sort of problem. It depends on the attributes/requirements of your app. Here are some hints:
If you have interesting domain logic consider using JPA with rich relationships and behavior in your entities (domain model -- see domain driven design). This has been my preferred way for a long time.
If your app is a simple CRUD app (data maintenance without a lot of deep domain logic) you can probably get by without JPA (but I'd personally still use it for convenience), and the simplest possible way to get the basic functionality done. The minimal business logic can be achieved in "transaction scripts" in a service layer.
If you have to do operations across lots of row s in the DB, and runtime is of the essence, then consider stored procs. This,for me, is a last resort due to lack of easy testability and maintenance/change control. However there is no better way to get huge performance benefits when really needed.
You can mix and match the above, IMO. But I'm a pragmatist not a purist.
One thing to keep in mind is the "lower down" in your system the business logic lives, the more reusable it is. That is one reason I have a fondness for the DDD approach. But it is not applicable for every situation.
来源：https://stackoverflow.com/questions/18216521/what-are-the-design-consideration-questions-in-determining-where-to-place-the-bu