Summary of L3 architecture (III)

On Christmas Day, two friends (two beautiful MMS) talked about the implementation of the N-layer architecture on island coffee. They use Java, and the architecture is strictly in accordance with the J2EE model. Of course there are a total of seven layers (my day! Big Program ). After hearing their descriptions, I still merged the seven layers into three layers (DAL, BLL, UI ). The implementation method is different. I also learned something from it.
First, let's talk about the UI. The page Jump in the web layer uses the config file configuration. For example, when page a is about to jump to page B, some functions or operations are executed to obtain a forward value, based on the value of the forward, go to the config file of the corresponding web layer to find the page to which it should arrive. The advantage of using this method is that the page Jump is very flexible. At this time, I remembered that when we made a page Jump Code If you want to jump to the same specified page on several pages written to the page's CS or aspx, you need to write some code in these pages. If the specified Page name changes, you need to modify all the jump codes on these pages. They did a good job.
In addition, when talking about the business layer, we need to talk about the business logic. At this time, we have to involve the database table structure. They do not advocate the use of foreign keys in the table structure. Generally, link tables are used as links. For example, in the employee and department tables, departid is not used as the foreign key, but the employeedepartlink table is used as the join. In the relational table, only the employeeid and departid are supported. The employee table only contains information about the employee. I personally feel that the advantages of doing so are: During in-depth development, the expansion of the employee table will not be caused by the increase of information associated with the employee, and the structure of the employee table is fixed. However, in this case, the information connection is doubled during query. For example, to display a person record and his department, you need to query three table sets. if you add a foreign key to the employee table, you can reduce the set connection of one table.
Let's talk about the persistence layer. What they call the persistence layer is the data access layer. Of course, this layer is divided into three small layers. There is an interface layer (DAO) between the business layer and the persistent layer ). What attracts me more is the EO layer. Each data table corresponds to one EO, and there are only some public attributes in one eo. These attributes correspond to the fields in the corresponding table. My understanding is that there is a layer outside the database.
At this time, I came into contact with a question that I am more concerned about. How do I deal with the query of the set connection on the business. The conclusion is that most of their queries are for a single table. If there is a complicated query, write the SQL statement directly. Dizzy, I am so excited for a long time. What I have seen in the structure is either to sacrifice the integrity of the Performance-preserving architecture (as I wrote in my summary of the three-tier architecture (I ), either it is to sacrifice the performance of the architecture, and I personally prefer to retain the performance. Of course, in the page display design, we try our best to ensure that the content of a data table displayed is read from a table.
I don't know if my current understanding is correct? My understanding is: Due to software architecture restrictions, it is possible to consider the limitations on user functions and the content displayed on the page and the display method during the design, try to break down function operations into single-Table atomic operations, and try not to operate multiple tables at the same time. This can also reduce the concurrency problem.
Finally, I learned from this talk that it is not recommended to use a large number of stored procedures in databases for large projects. This is also indicated by some online materials. Later I understood that this was done to reduce the workload of the server. Think about it too. In fact, a large part of the operation in a system is to fill in and delete a single table.