Three-tier architecture new ideas

A three-storey project.

Now that the three floor is too popular, I think at least 50% of the projects of a slightly larger scale are three floors. I have also developed a number of three-level projects, and finally see the three layer on the development of the three layer of the consequences.

What is a small scale project, take the project I developed as an example, (to promote the development of the project, sorry)

such as www.ungou.com/http://www.yinggou.com/http://www.doocn.com/

To be honest, I don't mean to advertise, nor face, because these three projects are three-level losers (because I am not the boss of the project), the consequences I do not say everyone knows: chaos, maintenance is difficult.

Three layers of new ideas

Data Access Layer

1. Data access layer should not have transactions, should only be very pure increase, delete, change, query, whether there are more general data access methods.

2. Changes in business requirements should not result in modifications to the layer's methods (except for adding fields, etc., and the need to have a table associated with them) to determine whether a qualified data access layer can use this rule.

3. The method in the data access layer is a very pure small part (or block bar) for the business layer. For example, one way to add a user is simply to add a user and no more action logs will be inserted into the log table. The advantage of this is that the method is clear and stable (adaptable to changes in requirements, once code is generated, Rarely make changes, it's called stability.

4. The method of the data access layer is not to say that there is no transaction involved at all, often to determine whether the current thread context has a transactional presence, a transaction is performed by a transaction, and no transaction creates the connection object on its own.

Business Layer

1. The most important task is to call the methods in the data access layer according to the business requirements, just like building blocks, building blocks can have a lot of tricks, just as business needs are the same. For example: Adding a user method to the business layer might be like this:

Start a transaction

Insert User

Insert Action Log

Commit a transaction

2. The change in most business requirements should be as long as modifying the code in the business layer, such as adding the user's requirements to the above, and assigning roles when users are added:

Start a transaction

Insert User

Insert User Role table (user ID)

Insert Action Log

Commit a transaction

Performance Layer

Don't talk about it.

Data-tier and business-level benefits based on this design

1. Because the data access layer's method is like the building block, the granularity is very low, very general, may the code generation, the business change basically also does not revise the change layer code, is very stable very good.

2. Business layer code is very flexible, are some of the core business code. There's a lot more code than the data access layer. Often hear or see a lot of people say "the business layer in layer three code is like a forwarder, no code, turn the data Access layer method to complete the task, like a redundant layer", This statement in the Java project as often exists, although the Java project has always been the world's most widely regarded as more standardized, (net projects are often said code is very messy, very local characteristics, everyone has the way everyone, haha).