Standardize. NET application development)

Once you get the appropriate security components, you are ready to study your data access methods. The common mistake in this regard is to develop everything on the display layer, including your business logic and data access components. This kind of development makes it difficult to maintain code like pasta (see resources ). It also makes it difficult and expensive to change the database plan or to a new database, because you must find all the independent data access calling commands distributed in your application. Using four layers to build your enterprise-level applications-the display layer, workflow layer, business layer, and data access layer-makes your applications easier to maintain and more scalable.
This topic focuses on the data access layer. The application needs to clearly split the data access layer from the business object. You do not want SQL statements to spread across all the code from the display layer to the business layer. These layers do not need to know how the data is obtained and where it is obtained.
Microsoft contains two new objects, Dataset and DataReader, which are used as part of ADO. NET to separate each layer. Dataset objects are useful for an unconnected application mode, while DataReader objects are used for connected applications. However, these objects have one drawback: When you access the attribute values, they can be searched by name or column number. When data is accessed by column names, if there is a typo in these names, it will not be detected during compilation. When column names are scattered in your code, it is difficult to change their names later. If you access data through column numbers, the code is more difficult to read, and you need to know the order in which columns appear in Dataset or DataReader.
Use stronugly Typed Datasets
Stronugly typed datasets solves this problem, but you cannot always use Dataset objects. When you use a Dataset object, it reads all records into the memory. In a large number of applications, server resources are exhausted. However, if DataReader is used, there is no object equivalent to stronugly typed Row. One method is to repeatedly use Dataset and DataReader to form a strongly typed object, which is ideal.
One method I use is to use a Proxy object and a Domain object for each table. The Proxy object contains SQL statements or stored procedure call commands to obtain or save domain objects. The Domain object contains attributes to reflect the characteristics of the table. The business logic component interacts with the Proxy object and executes the business logic on the Domain object. This method limits the content of SQL statements or process names for the Proxy object. It provides a unified data access policy, improves the readability of application code, reduces runtime errors, and provides flexibility, if it is necessary to switch to a different database layer (see figure 1 ).
Figure 1. Display layers
We need to discuss more details about Proxy objects. A controversial issue is whether to use SQL statements or stored procedure calls in Proxy objects. Using Stored procedures is more effective than SQL statements. Therefore, some companies prefer stored procedures, but you should choose a method that is more suitable for your company. No matter what method you use, avoid splitting the business logic between the stored procedure and the commercial logic component. I like to store business logic in Business Objects. As an example, I provide a C # code list that displays the Proxy and Domain classes of an Authors table (see list 2 ).