. Net three-tier architecture-discussion (Part II)

I advocate layering. However, I personally think that the composition of a system is not as simple as that of a layer-3 system.

I am not clear about my position in the previous article. I am sorry,

Com is a milestone concept that Microsoft has helped programmers jump out of programming nightmares.

Component Object Model,

I prefer to think of it as the Common Object Model Public object model.

Each group of objects is used in various systems as a general solution.

There are some business requirements for configuration, login, security, and other services.

There are also some program design requirements to solve Object serialization, asynchronous transmission of requests, persistent objects, and so on.

There are also some requirements for UI personality beautification.

These object models are called by the business layer according to their own rules as an independent system.

 

At the business layer, an e-commerce system is used as an example to describe the sales, finance, warehousing, reports, logistics, customer relations, and so on. Each process can be separated into a business middleware,

They are replaceable and can be reused by other e-commerce systems, or new rules for adding a member discount.

If it is only weak coupling between layers, for example, changing the logistics relationship will affect the financial design ....... you will be cursed by the programmers who will take over the maintenance in the future...

 

Sometimes, to improve performance, some simple business logic is dispersed into JavaScript/client,

Sometimes, some difficult-to-design business processes are directly written to the stored procedures.

These are understandable.

If you forget the Layer 3, try to think about which functions are reusable and which practices are more conducive to improving system performance.

Reduce dependencies between various business processes. If a business link involves a change to the entire business layer, your design will undoubtedly fail.

Requests that are frequently accessed should go through as few layers as possible and directly reach the database. Your customers will never care about what Layer 3 your program design is.

 

 

Postscript

As for the big company I mentioned in the previous article, Everything is written into the stored procedure,

I never said he was right,

The current situation of the company is that the application server performs load balancing, but eventually it needs to access the same dbserver.

Now, Lao Tzu needs to analyze their stored procedures and propose optimization solutions every day,

It is even possible to redesign those stored procedures, put them back on the application server, simplify them, and then go to dbserver for query.

If there is a stored procedure without annotations or data dictionary, it is really annoying.