Practical .NET Data Access Layer - 19

zhaozj2021-02-16  62

6. Aspect

AOP (aspect oriented programming) may be excavated in recent years

One of the most powerful technologies, the author doesn't plan to introduce it here (online information is much like a magic), just want to use its Aspect concept to explain the problem that must be considered when designing Data Access Layer (also Several important factors that have to be considered before system architecture design!):

(1) Security

Take it in Aspect first believe everyone has no doubt!

Although, Business Logic has set too many Security Issues for us, but the long-lasting "Connectionstring Shadow" will become a "uncomfortable" in many developers!

A colleague told me that Microsoft had an ASP.NET app that is known as 80,000 people, and its connectionString actually exists in Registry (don't forget to disable Remote Registry service)! Such a double protection (the other is encrypted for Connectionstring) is how simple is it!

In many cases, As Simple As Possible is the goal we should really pursue.

Another problem that needs attention is how to deal with SQL INJECTION (SQL injection) attack!

A classic example is as follows:

String strsql = "SELECT * from User Where"

"Username = '" strusername

"'and password ='" strpassword;

Here, the Dynamic SQL itself is not called the logic problem, but it gives Cracker to be a machine: if the system has done any data check for Strpassword, when the user tries to enter "ABC" as Username, " 123 'or 1 = 1 "As Password, then I have to tell you: The system has been successfully broken, please quickly release new patches!

Although this example is very simple, we have reminded us that small SQL statements will become the "important source of" "important sources" of system vulnerabilities!

In this case, it is also very simple to avoid the crisis: use Stored Procedure or Parameter Collection (you will not tell me to prepare this responsibility to the Business Logic staff who don't have SQL experience J). If the system architecture is not ready to use Stored Procedure or developer very uncomfortable to use Parameter Collection (frankly, I don't like this stuff), then there is a slightly trouble Solution (of course not recommended):

i. Use username to assemble Dynamic SQL;

II. Judging whether the number of records is 1 (assuming username is Unique Column);

Iii. If the number of records is 1, remove the password data;

IV. Judging whether the Password that the user enters PASSWORD matches the query. Limited to the space, here only discussed two more common problems, of course, it is far from covering all the essence of Security, just to show a point of view: Security is very important, don't wait for the leisure!

(2) Transaction

This is an unavoidable stuff, and it is difficult to find its problem, and it is not easy to test! The author is not ready to start this, and everyone only has experienced experience through actual intensive.

In addition, in the end, SYSTEM.EGINTRISSERVICES is still Connection.Begintransaction try-catch, still makes a lot of .NET developers have confused, as part of the system architecture design, this is also a problem that must be fully considered!

(3) Logging

The log is not a problem that you want, but how to do it.

Log4net is already very good, I will not want to do one by yourself!

(4) EXCEPTION

This is a "no hole", see how you design.

It is mainly used in such a way on the author's project.

I. One Throw, One Catch, No Re-Throw

This is the easiest, don't need too complicated Exception Inheritance Hierarchy, which is relatively easy to process;

Ii. One Throw, Multi-catch, Multi-Re-Throw

Complex applications may adopt this mode more, need a lot of Exception Classes and the desired TRY-CATCH, but it may be more excellent in scalability and fault tolerance. )!

Think of this temporarily, if you have any omissions, you are welcome to add.

Next paragraph: http://www.9cbs.net/develop/read_article.asp? Id = 27564

转载请注明原文地址:https://www.9cbs.com/read-24089.html

New Post(0)