Knowledge base:. NET Application development standardization

Standard | procedure

Developing an enterprise application is a complex process. You can use Microsoft. NET technology many tools to make this process faster and easier, but because. NET complexity, it is difficult to choose the most direct method. If there are no clear criteria and guidelines to use to develop applications, each development team in the enterprise may replicate development in security, database access policies, and testing processes. Although each group may develop effective methods in these areas, it can lead to unnecessary duplication of effort. And for important security, if each development team determines their own security implementation methods, the application can become vulnerable to attack.

If you work in an IT group, this is a very common situation. Luckily, you can keep things simple. Although every application developed in an enterprise solves a unique business problem, you can build all your applications on the same underlying framework components. The best way to develop standard and public from naming conventions to preinstalled components that reinforce application architecture. A common Application architecture component, your development team can save time, make sure your application is secure, and improve collaboration between groups. The scope of the standard is very wide,

In this article, I'll explore the best way to implement a common application Architecture framework in an enterprise. I will pay special attention to three main areas: Application security, database access policies, and test procedures. I'll talk about verifying your users ' identities, building your enterprise applications with four tiers, and talking about two new Microsoft Objects--dataset and datareader--they are part of the ado.net that can help you separate layers.

The use of pre-installed components is a good way to strengthen application architecture and provide general services. Because the application architecture is an enterprise-class problem, you may not have a team in your existing organizational structure to undertake this work. However, the formation of such a group is very simple, you only need to redesign the various groups, and then allocate a number of highly skilled personnel (already in your company) to work on the application structure.

When you introduce a common, low-level framework application, teams may focus on business issues rather than on structural concerns. This gives us little technical requirements for developers who do each application. As a result, development progress will be shortened to better respond to market conditions. The combination of all these factors will reduce investment in development and maintenance and ultimately increase your company's profitability. However, you first need to build a common, low-level framework in three main areas: Application security, database access policies, and test procedures.

Security is important and you should control this aspect of the application structure from the early stages of development. Proper user authentication and authorization can guarantee the security of an application. In the absence of a centralized security component, it is dangerous for each team to write its own security code. A central security policy not only enables developers to avoid duplication of effort, provides the same level of protection for all applications in the enterprise, but also creates a structure that allows all modifications to occur in one place without creating new security vulnerabilities. The first step in the security architecture is user authentication.

　　Verify your user identity

A typical enterprise needs to verify the identities of two types of users: internal users (employees) and external users (suppliers and customers). Your organization should establish a unified strategy to verify the identities of these two types of users and authorize them.

In traditional ASP, user authentication and authorization are difficult to implement if you do not use Integrated Windows authentication. For example, it is not easy to determine that each user identity has been validated. Each ASP page requires code to verify the user authentication cookie and to prove that the user identity is determined. In ASP.net, authentication and authorization are much easier than in traditional ASP. In ASP.net, there are three forms of authentication: Windows authentication, Passport authentication, and forms validation.

Windows validation is simple for simple applications. It authenticates user identities based on active Directory (AD) for the current domain. User groups are used as roles for role-based validation. The role of the user group may not be as granular as the application requires, so they must exist in another database or in their own ad; Windows validation does not change these roles.

Passport validation is part of Microsoft's. NET My Services policy, which is used to authenticate users in an Internet program. Passport is a single sign-on (SSO) service that allows registered users to access related sites with a single user ID and password. The Microsoft Passport server is responsible for maintaining user identity information and providing a validation mechanism. The Passport's wallet feature provides users with the option to store their credit card information and share it with the site. If the site needs more information, they can get that information in their own database and combine it with the Passport user ID. This is good for the user because her information is stored centrally and she does not need to repeat the information when visiting each site. For an enterprise, this validation has a bad place, because they have to trust a database, and they have no control over the library. So far, passport verification has been difficult to use widely and has become a viable verification method.

Unlike passport validation, forms validation is flexible, and you can insert custom validation code and develop common security components. You can configure it in server-side machine.config, and once the configuration is complete, the component is automatically plugged into all the applications on that server.

　　Research security Components

Asp. NET provides a good way to insert new functionality into the path of the request execution with HttpModule. Developers can create custom HttpModule to authenticate internal/external users, establish user roles, and create a custom primary object. For a simple custom HttpModule, you can download the code sample (see Listing 1).

You may also want to consider some of the other features of your security component. For example, it would be nice to have a security management console. This provides the facility to define the application role, to authorize the role (URLs and actions), and to grant the user a role. When you have a console application, you can delegate administrative responsibility, including security settings. When people change roles, the application functions change for a given role, and the components are useful.

You may want to extend the security module to view the URL and its operational code and see if the user is authorized. Each resource or URL in an application can have multiple procedures, such as view, create, update, and delete. This is useful if you can control user access on an operational rather than a resource. This allows the ASP.net page to get a list of actions for the users concerned, without worrying about what role the user has. Finally, consider providing ASP.net server-side component personalization, implementing the Application menu based on user capabilities.

Once you have the appropriate security components, you are ready to study your data access methods. The common mistake people make in this area is to develop everything at the display level, including your business logic and data access components. This development leads to a difficult to maintain code like spaghetti (see Resources). It also makes it difficult and expensive to change the database plan or to change it to a new database, because you have to find all the individual data access call instructions that are scattered across your application. Building your enterprise-class applications with four tiers-the display layer, the workflow layer, the business layer, and the data access layer-makes the application easier to maintain and more scalable.

On this topic, I will focus on the data access layer. Applications need to significantly separate the data access layer from the business object. You don't want the SQL statements to spread across all the code from the display layer to the business layer. These layers do not need to know how data is obtained and where it is obtained.

Microsoft contains two new objects--dataset and datareader--that separate layers as part of the ado.net. The DataSet object is useful for a disconnected application pattern, while the DataReader object is used for connected applications. However, these objects have a disadvantage: when you access the value of a property, they are searched by name or by column number. In the case of accessing the data by the name of the column, if there is a typo in those names, it will not be detected at compile time. When the column names are scattered in your code, it's hard to change their names later. If you access data by column number, the code is more difficult to read, and you need to know the order that appears in the DataSet or DataReader.

　　Using strongly Typed datasets

The strong type (strongly typed) datasets solves the problem, but you can't always use the DataSet object. When you use a DataSet object, it reads all the records into memory, and in a large number of applications, server resources are exhausted. But if you use DataReader, there is no object equal to the strongly typed row. One way is to use datasets and DataReader repeatedly, which can form strongly typed objects, and is ideal.

One of the ways I use it is to use a proxy object and a domain object for each table. A proxy object contains SQL statements or stored procedure call directives to get or save a domain object. The domain object contains attributes to reflect the attributes of the table. The business logic component interacts with the proxy object and executes business logic on the domain object. This method restricts the contents of the SQL statement or procedure name for the proxy object. It provides a unified data access policy that improves the readability of application code, reduces Run-time errors, and provides flexibility if it is necessary to convert to a different database layer (see Figure 1).

You should use a loosely coupled layer to build your application. This can improve the maintainability, scalability, and reusability of your application. This method contains a proxy object and a domain object for each table. A proxy object contains SQL statements or stored procedure tuning to get or save a domain object. The domain object contains attributes to render the attributes of the table.

It is necessary for us to explore more details about the proxy object. A controversial question is whether to use SQL statements in proxy objects or to use stored procedure calls. Using stored procedures is more efficient than SQL statements. So some companies prefer to use stored procedures, but you should choose a way that suits your company better. Regardless of the method you use, avoid splitting the business logic between the stored procedure and the business logic component. I like to keep business logic in business objects. As an example, I provide a C # code list that shows the proxy and domain class for a authors table (see Listing 2).

The final step in the application Architecture framework that you need to consider is the testing process. Testing is important in the development phase because it is the only way to prove that the software works. However, when time is pressing, such as when the release date is approaching, the test usually appears to be in a secondary position. And in most cases, testing the job requires people to focus and take responsibility. Every time the code changes, people need to repeat the testing process rigorously.

A new methodology for software development, extreme programming (Extreme Programming), introduces a rigorous software development approach that keeps the final product deliverable, user-satisfied, and qualified (see Resources). It is built on a test-based development philosophy that encourages developers to write test cases before they write the actual functional code. All test cases are developed as classes that test the functionality of the business functional class.

Once you have a test case as a class, you can repeat the test at any time. If all the test cases don't work, you'll know there is a problem. This test method is especially effective when existing code is changed (there is a good chance that something is corrupted).

To make testing easier, the founder of the Extreme Programming method, Kent Beck, created a simple framework called JUnit that allows people to write test cases in Java. As. NET program "Factory", you can use the same open resources nunit (see Resources). It is based on JUnit's original concept, and you can integrate it with Visual Studio. NET (vs.net). It allows you to include test classes and functional classes in the same project. Having test classes and functional classes in the same project allows for effective testing. Each time a functional class changes, you do not need to convert the project to test. During the development cycle, you add the test method to the test case class, add functionality to the business class, and then run the test case. The test class is also integrated with the business class in Visual SourceSafe. When you take the test as an integral part of the development process, your code quality improves and the repetition test is simple. It also eliminates the fear caused by changing the code.

Now that you know the steps to building a common application structure, you are ready to use them in your business. Establish an active group to take responsibility for the underlying framework of the public and its prospects. Each enterprise builds its own application and invests in it. Creating a common, low-level framework can help you develop higher-quality applications faster and with less investment.

　　About the Author:

Rao Chejarla is an independent software consultant. He focuses on software engineering methodologies and application structures that use the. NET framework and Java EE. He has more than 12 years of experience in software development, design, and architecture. His contact method is kotrao@yahoo.com "> Framework and Java EE application architecture." He has more than 12 years of experience in software development, design, and architecture. His contact method is kotrao@yahoo.com.