How to create and archive Java / Java EE web application?

Question

I am a Java developer with almost 5 years of experience with Struts, Spring and Hibernate.

We have a new project in a few days. We have full requirements for us, and we will do this project using Spring MVC, Spring and Hibernate.

I was asked to design and archive the entire web application. Designing and creating an architect is something that I have not done so far in my career. And I don’t know how to do this and where to start, what tools to use and so on. I don’t even know A, B, C of design and architecture.

You might be wondering why I even asked you to do this in the first place. The fact is that I was given the opportunity to do this, and at each stage they will control me, and I will have my elderly people who are considering design.

Therefore, any suggestion, ideas and steps to start and continue are welcome.

Answer 1

I can add my 2 cents from my own experience (although this is rather a compilation of best development practices, it might seem useful to remember them when developing your application):

• Design without a single size
• Try to keep the application as light as possible.
• Use Maven / Gradle to Manage Dependencies
  • Do not rely too much on the IDE. Make sure your project is built without an IDE (if you use maven / gradle, it will :) Try opening the project using IDEA, Netbeans and Eclipse.
• For the technologies mentioned above, appfuse makes a good starting point.
• First create your database / entity.
• Use libraries wisely and wisely. DO NOT use them.
• Remember to write JUnit / TestNG (at least for the service level).
• Test the application on all major browsers (and not just on your favorite).
• Determine how many total users and how many concurrent users your web application will have.
  
  • Then decide whether to cache or not.
  • you will use a cluster of application servers or not.
• Choose an application server based on its capabilities and, more importantly, “your needs”,
  • Tomcat / Jetty is absolutely suitable for most occasions.
• Avoid using any app-server api applications
• Use of JPA interfaces / annotations, even if using sleep mode as a JPA implementation
• Be careful when matching relationships in objects. Decide which properties and relationships will load lazily and which will load impatiently.
• When developing an application, consider application security. Spring security is a great choice.
• Never abuse HttpSession. Do not store too much in it.
• Preserve Entities Serializable. Forced developers use toString (), hashCode () and equals ()
• Remember to use version control from day one.
• Do not consider spring / hibernate / spring -mvc to be the best choice for you. create a little proof of concepts with parameters from 3 to 4.
• Try automating integration / build / deployment with CI tools like Jenkins
• Check and tune SQL generated by Hibernate (from time to time)
• Do not allow business logic to enter the view layer. Hate jsp scriptlets? Consider Speed ​​/ Freemarker. JSP is not the only option.
• External environment customization using the Spring PropertyPlaceholderConfigurator.
• If possible, try integrating with your existing user authentication mechanism (such as LDAP / OpenID) rather than writing yourself. This will save you from rethinking the wheel and your users from remembering another set of username and password.

Answer 2

There are a few things you will need in architecture design documents. It’s not an easy task, but props are possible. Since this is such a big question, I hope these links help you get started, and you can clarify the questions after your feet become wet.

Methodology

The methodology you use will affect what tasks you perform first. Waterfall is a popular but outdated methodology. A newer methodology is Agile, which has several faces. My favorite Scrum Agile for software development of any size.

Diagram

Diagrams is one of the most powerful ways to represent the system as a whole and the individual components. The type of diagrams you create depends on the system. Usually there are structural diagrams, behavior diagrams, interaction diagrams and tons of others. These diagrams show fragments of the system as a whole, each physical layout of components and / or logical layout, communication flow, flow of procedures, etc.

Documentation

Documentation is similar to sounds, documents, and documents that contain descriptions of projects, scope, user examples, sequence diagrams, and any other document that describes a project or fragments of a project.

Answer 3

Browse the Agile Modeling website, which encourages simple modeling. They have excellent recommendations, including a complete “flexible modeling process” from collecting design / development requirements.

http://www.agilemodeling.com/

http://www.agilemodeling.com/essays/amdd.htm

http://www.agilemodeling.com/essays/agileArchitecture.htm

http://www.agilemodeling.com/essays/agileAnalysis.htm

http://www.agilemodeling.com/essays/agileDesign.htm

As for tools, I like Visual Paradigm. It is relatively inexpensive (compared to other tools). There are many free modeling tools (google is your friend), but not one is compared to Visual Paradigm, and for the bit it costs, it's worth it. If my employer hadn’t counted the cash, I would have bought it myself ... :)

Answer 4

Take a look at Robert Martin (aka Uncle Bob) "Clean Architecture." Here is a quick overview. Using this approach, you can defer details such as Spring or Hibernate in more detail and focus more on business logic. Or even switch from Spring to Java EE without touching your business logic and application. You will also receive a test application that complies with SOLID principles, without much effort.

I just created the application in this way, and I must say that I am very pleased with it. I could easily transfer it to a desktop or mobile application or change the storage module. Details depending on the policy go a long way. It also promotes thinking in the API view and, when used correctly, makes your modules very reusable.

Martin says that details like frameworks are annoying, not part of your architecture. I think they belong to architecture, but only at a different level. Often you want to enable frameworks at an early stage in order to be able to create a thin fragment of a working application for demonstration to your users. Or when you know your framework in advance, and there isn’t about them, as in my case. But you can think of it as separate software architectures when they together create the architecture of your application.

Answer 5

more details

• Before you begin coding, remove the business requirements. Create a complete list of requested features, sample screenshots (if any), usage diagrams, business rules, etc. As a functional specification document. This is the stage at which business analysts and developers will ask questions about user interface requirements, data level integration requirements, use cases, etc. Also prioritize functions based on business goals, deadlines, and iterations needed to implement.

• Prepare a technical specification document based on a functional specification. The technical specification document should cover: Purpose of the document: for example. This document will focus on customer service functionality. Overview. This section mainly covers background information, scope, any inclusions and / or exceptions, referenced documents, etc. Primary architecture: Discusses or refers to a basic architecture document. Answers to questions, how will it be scale? Can this performance be improved? Is it extensible and / or maintainable? Are there any security issues? Describe the vertical slices that will be used in the early iterations, and the concepts that must be confirmed by each slice. Etc. For example, which MVC models [model-1, model-2 etc] should I use? Should we use Struts, JSF and Spring MVC, etc. Or create your own structure? Should we use a business delegate to separate the middle tier from the client tier? Should we use AOP (aspect-oriented programming)? Should we use dependency injection? Should we use annotations? Do we need internationalization? Etc. Assumptions, dependencies, risks and problems: highlight all assumptions, dependencies, risks and problems. For example, list all the risks that you can identify. Design options for each key functional requirement. Also discuss why a particular design alternative was chosen over others. This process will encourage developers to analyze possible alternatives to the project without moving to an obvious solution that may not always be the best. Processing logic: Discuss the processing logic for the client tier, mid tier, and data tier. Add process diagrams if necessary. Add any pre-processing conditions and / or post-processing conditions. UML diagrams for transferring design to developers, solution developers, architects, etc. Class diagrams and sequence diagrams are usually required. Other charts can be added for any special occasions. State diagram: useful to describe the behavior of an object in several uses. Activity diagram: useful to express complex operations. Supports and encourages concurrent behavior. A diagram of activity and state diagrams is useful for modeling workflows with multi-threaded programming. Interaction and sequence diagrams: use a collaboration diagram or sequence diagram if you want to look at the behavior of several objects in one case. If you want to look at one object in several use cases, use the state diagram. Object diagrams: Object diagrams show instances instead of classes. They are useful for explaining in detail some complex objects, such as highlighting recursive relationships. List package names, class names, database names, and table names with a brief description of their responsibilities in tabular form.

• Prepare a coding standards document for the entire team to increase consistency and efficiency. Some encoding methods may degrade performance, for example: Improper use of the String class. Use StringBuffer instead of String for heavy computing. Code in terms of the interface. For example, you may decide that LinkedList is the best choice for any application, but later ArrayList might be the best choice. Incorrect approach List ArrayList = new ArrayList (); The correct approach List list = new ArrayList (100); Set the initial collection capacity appropriately (e.g. ArrayList, HashMap, etc.). To increase consistency, define standards for variable names, method names, use of logs, curly braces, etc.
• Prepare a document and templates to review the entire team. Let's look at some of the elements that a code overview should cover: Proper declaration of a variable: for example. instance against static variables, constants, etc. Performance issues. Use ArrayList, HashMap, etc. Instead of Vector, Hashtable if there is no thread safety issue. Memory problems: for example. Incorrect creation of objects instead of reusing objects and combining objects, rather than closing a valuable resource in a finally block, etc. Thread protection problems: for example. Java API classes such as SimpleDateFormat, Calendar, DecimalFormat, etc., are not thread safe, variable declarations in JSP are not thread safe, storing status information in the Struts action class or multithreaded servlet is not thread safe. Error handling: for example. Re-throwing exception without nesting the original exception, EJB methods do not throw an EJB exception for system exceptions, etc. Using coding standards: without using frameworks, System.out is used instead of log4j, etc. Design problems: code reuse, lack of clear separation of responsibilities, invalid use of inheritance for method reuse, servlets that perform direct JDBC access, instead of using DAO (Data Access Objects) classes, HTML code in Struts actions or servlet classes, servlets are used as utility classes, not as a stream controller, etc. Code documentation: e.g. No comments, no header files, etc. Errors: for example. Call setAutoCommit in a container-managed transaction, binary OR "|" used instead of the logical OR "||", relying on pass-by-reference in remote EJB calls, the ResultSet does not close on exceptions, EJB methods do not throw an EJBException for system exceptions, etc.
• Prepare additional optional guidance documents as required by the team. This will promote coherence and standards. For example: Recommendations for creating a J2EE development environment. Recommendations on the version control system (CVS, VSS, etc.). Recommendations for deployment steps, environment settings, ant goals, etc. Recommendations for data modeling (any company standards). Recommendations for error handling. User Interface Design Guidelines. Project Review Document, Software Development Process Document, etc.

Answer 6

I edited a new book on Spring, Hibernate, and Data Modeling that will answer your request regarding the design aspects of a Java EE web application. Typically, a Java EE web application has 5 levels — client, presentation, business service, data access, and resource (entity). The book focuses on how to design and develop each of these levels, taking examples of all the relationships of data modeling using Spring and Hibernate. The entire web application is provided as a download, in which you will find information on managing each relationship of the data modeling scenario.

Look at a simple standalone object. To manage an entity, you must create methods such as creating, reading, updating, deleting, and searching for all records. Therefore, if we go from bottom to top, creating an entity forms the first step. Then we look at the repository, which has the methods described above. Next comes the service level, and then the Spring REST controller, which is based on JSON. The rest of the task involves coding the JSP page and calling JQuery AJAX for the REST controller.

Read more about the book here.