Though these architectures all vary somewhat in their details, they are very similar. They all have the same objective, which is the separation of concerns. They all achieve this separation by dividing the software into layers. Each has at least one layer for business rules, and another for interfaces.
Each of these architectures produce systems that are:
Independent of Frameworks :
The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints.
The business rules can be tested without the UI, Database, Web Server, or any other external element.
Independent of UI :
The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.
Independent of Database :
You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.
Independent of any external agency :
In fact your business rules simply don’t know anything at all about the outside world.
A model presents the state and core business logic. Data present in database is mapped by the model and holds the core business logic.
A View renders model’s contents. Data is accessed by a view from the model and display logic is added for presentation of the data.
A Controller performs the function of glue between a view and a model. Requests are delegated by controller for state and application logic. Logic gets centralized to dispatch the requests to next view that is dependent upon the input parameters from application state and client. Servlet and JSP pages are decoupled by controller, by view selection handling.
Points to be considered while designing J2EE applications:
- Try to keep application as lightweight as possible.
- Use Maven/Gradle to manage dependencies
- Design your database/entities first
- Use libraries sensibly and judiciously. Do NOT overuse them.
- Don’t forget to write JUnit/TestNG (at least for service layer)
- Test application on all major browsers (not just your favorite one )
- Determine how many total users and how many concurrent users your web app will have for load balancing
- Then decide whether you need caching or not.
- you will use app server clustering or not.
- Select the application server based on its capabilities and more importantly ‘your needs’
- Tomcat / Jetty are absolutely fine for most of the cases
- Avoid using any app-server specific api
- Use JPA interfaces/annotations even if using hibernate as JPA implementation
- Be extra cautious while mapping relationships in entities. Decide which properties and relationships will load lazily and which will load eagerly
- Keep application security in mind while designing the app. Spring security is excellent choice.
- Never abuse HttpSession. Don’t store too much in it.
- Keep entities Serializable. Enforce developers to use toString(), hashCode() and equals()
- Don’t Forget to use version controlling from Day 1
- Don’t just assume that spring/hibernate/spring-mvc will be best choice for you. create small proof of concepts with at least 3 to 4 options.
- Try to automate integration/build/deploy with CI (Cloud Integration) tools like Jenkins. E.g. Cloudbee
- Check and Tune SQL generated by Hibernate (time to time)
- Do not let business logic creep into view layer. Hate jsp scriptlets? Consider Velocity/Freemarker. JSP is not the only option.
- If possible, try to integrate with existing User Authentication mechanism (Like LDAP/ OpenID) rather than writing your own. This will save you from reinventing the wheel and your users from remembering yet another set of username and password.