Microsoft PETSHOP 3.0 Design and Implementation Analysis Report --- Data Access Layer
Recently, you are very interested in multi-layer systems and .NET, learn to analyze Microsoft's multi-layer example system --petshop, the current version is 3.0, this version and previous version have a certain difference from design, should Yes, with Java's PETSHOP design is quite.
About some Microsoft PetShop, how to install, the performance business process, database table structure, and 3.0 version of the basic version of the basic information, etc., please refer to the article below.
http://msdn.microsoft.com/library/en-us/dnbda/html/bdasamppet.asp
In addition, I recommend watching this article first:
http://msdn.microsoft.com/library/en-us/dnbda/html/petshop3x.asp
This article will be analyzed in the way designed and implemented, which is also our greatly practical software developer style. Let's take a look at the form of design and specific implementation of the VS.NET project.
MSPETSHOP 3.0 system structure diagram:
From the figure, you can see that the system is generally divided into three layers of Presentation, Business Logic, Data Access, and sub-layers per layer. Each layer (also included sub-layers), and cooperates with each other, this paper is subject to this chart, and the description of the next analysis.
Corresponding to the image, the specific .NET Project implementation list (using the list in the MS article without translation)
PROJECT
Purpose
BLL
Home for Business Logic Components
Configtool
Administration Application Used to Encrypt Connection Strings and Create Event Log Source
Dalfactory
Classes use to determine Which Database Access Assembly To Load
IDal
Set of interfaces which need to be used by Each Dal Implementation
MODEL
Thin Data Classes or Business Entities
Oracles
Oracle Specific Implementation of The Pet Shop Dal Which Uses The iDal Interfaces
Post-build
Project To Run Post Compile Actions Such As Adding Assemlies To The Gac Or Com
Pre-build
Project To Remove Assemblies from the Gac or Unregister AssemBlies from Com
SQLServerdal
Microsoft SQL Server Specific Implement Of The Pet Shop Dal Which Uses The iDal Interfaces
Utility
Set of helper classes inclished a wrapper for the dpapi
Web
WEB PAGES AND CONTROLS
Solution items
Miscellaneous Items Used to build the application such as pet shop.snk key file buy to sign application askASEMBLIES
In addition, I wrote this article, I wrote on the side of the source code, so I would like to install a PETSHOP3, because the time is rushing, if I don't have anything, please send me email correction. Email: cocoboy79@163.com QQ: 364941 Let's take a look at the DAL layer.
One: Data Access Layer:
1 Petshop.utility is shown below: (UTILITY is implemented in the above table)
This name space has two classes, a class is the DataProtector calls Crypt32.dll and kernel32.dll implement some encrypted decryption security operations, and the ConnectionInfo class calls the DataProtector's feature to encrypt the Decryption database connection information, this ConnectionInfo provides the function of this ConnectionInfo In the following PETSHOP.XXXDAL namespace, you can see PetShop.utility plays a role of data access assistance tools. If you are interested in research encrypted decryption methods, you can take a look at the DataProtector's source code, and the use of Cryp32.dll.
2 petshop.sqlserverdal - System structure diagram DAL layer SQLSERVER DAL sub-layer implementation
The SQLHELPER class actually encapsulates some common functions about database operation access in this system, where it also calls the CONECTIONINFO class method in PETSHOP.UTILITY to encrypt the decryption connection string, such as: ConnectionInfo.DecryptdbConnectionstring method. The SQLHELPER class is based on Microsoft Data Access Application Block for .NET. This thing is used to help users access data in .NET. Such as MS passage:? Are you involved in the design and development of data access code for .NET-based applications Have you ever felt that you write the same data access code again and again Have you wrapped data access code in helper functions that? Let you call A Stored Procedure in One Line? IF SO, The Microsoft® Data Access Application Block for .NET is for you. In fact, you can write a similar SQLHELPER's thing to achieve the generalization of the database's operation to reuse in each item, of course, you can also use the current MS to do this SQLHELPER or Microsoft® Data Access Application Block for. .NET, avoid writing the same duplicate database access procedure in different projects. It is best to look at the specific program of SQLHELPER implementation and the Microsoft Data Access Application Block for .NET mentioned. But here our SQLHELPER should only be partially implemented. For more comprehensive information, please refer to: http://msdn.microsoft.com/library/en-us/dnbda/html/daab-rm.asp
The Account class operates to the user account such as INSERT, UPDATE, SIGNIN, where the operation of the database is implemented using the SQLHELPER class above. In addition, Inventory and ORDER, PRODUCT, PROFILE, and Account classes are equally operated on database-related tables, the program style, the operations of the database in these classes are performed by the SQLHELPER class under this name space, for example, the following statement : Private const string sql_insert_signon = "INSERT INTO SIGN VALUES (@UserID, @password)";
Private const string parm_user_id = "@userid";
Private const string parm_password = "@password";
To define a SQL statement, and declare the variable parameters, and use some XXXX parameters of the private method to handle the parameters in the above statement, and then execute with the appropriate method of the SQLHELPER class below:
SQLHELPER.EXECUTENONQUERY (Trans, CommandType.Text, SQL_INSERT_SIGN, SIGNPARMS);
Finally, in the SQLHELPER.EXECUTENONQUERY implementation, then call the relevant classes in ADO.NET to eventually execute the operation of the database, see SQLHELPER is here again to encapsulate ADO.NET related classes to optimize data operations. Just as SQLHELPER.CS Note Tips: The SQLHELPER CLASS IS INTENDED TO ENCAPSULATE High Performance, Scalable Best Practices for Common Uses of Sqlclient. Below is the implementation of SQLHELPER. EXECUTENONQUERY:
Public Static Int ExecutenonQuery (String ConnString, CommandType CmdType, String CmdText, Params Sqlparameter [] cmdparms) {
// Note: The argument of cmdtext at runtime is SQL_INSERT_SIGNON
SQLCommand cmd = new sqlcommand ();
Using (SqlConnection Conn = New SqlConnection (Conntring)) {
PrepareCommand (CMD, CONN, NULL, CMDTYPE, CMDTEXT, CMDPARMS);
INT VAL = cmd.executenonquery ();
CMD.Parameters.clear ();
Return Val;
}
}
Declarations of Inventory and Order, Product, Profile and Account are like public class account: Iaccount, which implements a related interface like Iaccount is declared in Petshop.IDal, see later.
3 PETSHOP.Oracledal --- System Structure Diagram of OracleDal sublayer
Personally think that the structure should be the above PETSHOP. SQLSERVERDAL, the other SQLHELPER becomes ORAHELPER, of course, in Orahelper, the connection operation of a specific Oracle database is specifically implemented, and the source program is obviously the original SQLCommand cmd = new sqlcommand (); It became oracleCommand cmd = new oracleCommand (). Note: There is also two XXX DAAB sub-layers in the system structure diagram, where is the corresponding implementation? The following correspondence:
The following is the left side is part of the DataAccesslayer in the figure, the right side is the name space or class of the specific implementation.
SQLSERVER DAL - PETSHOP.SQLSERVERDAL namespace
SQL DAAB - PETSHOP.SQLSERVERDAL.SQLHELPER Class
Oracle Dal - Petshop.Oracledal Name Space
Oracle Daab - Petshop.Oracledal.orahelper class
4 PETSHOP.IDAL Data Access Interface - Dal Interface in the Word System Structure Diagram
The interface is a series of declarations or lists of 'function'. The interface does not implement detail. If the interface Iaccount definition can also be seen that Iaccount is only claim:
Using system;
Using petshop.model;
Namespace PETSHOP.IDAL
{
// INTEFACE for the Account Dal
Public Interface Iaccount
{
// Authenticate a User
AccountInfo Signin (String Userid, String Password);
/// Get a user's address stored in the database
AddressInfo getaddress (String UserID);
/// Insert An Account Into the Database
Void INSERT (AccountInfo Account);
/// update an account in the database
Void Update (AccountInfo Account);
}
}
You only need to call the interface, not how the interface is implemented, then the interface is not implemented, call it? In fact, the implementation of the interface is made by a class, then the Iaccount interface here is implemented by the Petshop.sqlServerdal.account class or the Petshop.OracleDal.account class, from their definitions you can see:
Public Class Account: Iaccount {....}
There is a number of implementations of the same interface, so for the program that uses the interface, no matter how much less implementation is, it is always used, so that the appearance is unified. When the upper-layer BLL layer is called, this interface is not known which class is implemented. Who is to determine which type of implementation? Please look down again.
(Other interfaces under PETSHOP.IDAL are like IIITEM, IORDER, etc., so this is slightly.)
5 Petshop.dalFactory Data Access Factory
Factory model is a kind of design model, just like Factory words, I don't need to know how products produced in the factory, you can use things to produce it in the factory. MspetShop3.0 uses factory mode to implement the operation of SQL Server and Oracle database, and users don't need to know which database does not care about the rear desk, it is only necessary to use the interface, the interface is defined. The method to be used, which will call the underlying data access operation according to the specific situation when the interface is called. Now this DalFactory is the key. When the BLL layer wants to manipulate the database, DalFactory will use the SQLServerdal and OracleDal described herein as described in the specific situation. This allows the upper layer to adjust, and the next layer is realized, and only the upper level is applied, and the lower level is worked. For the upper layer, the implementation details are hidden. So how do DalFactory decides to use SQLSERVERDAL to use ORACLEDAL? We will then analyze.
The following is the implementation of the PETSHOP.DALFACTORY.ACCOUNT class:
Namespace petshop.dalfactory {
///
/// Factory ImplementAion for the Account Dal Object
/// summary>
Public Class Account
{
Public static petshop.idal.iaccount create () // <<< ----- Here you return to the interface
{
/// Look Up The Dal Implementation We Should Be Using
String path = system.configuration.configurationSettings.AppSettings ["Webdal"];
String classname = PATH ".account";
// using the eviden in the config file loading the appropriate assembly and class
Return (PETSHOP.IDAL.IACCOUNT) Assembly.Load (path) .createInstance (classname);
}
}
}
The following is part of the
The above CREATE () method returns the IACCount interface, with system.configuration.configurationSettings.appsettings ["Webdal"]; can get the Web.config
// Get An Instance of the Account Dal Using The Dalfactory
Iaccount Dal = PETSHOP.DALFACTORY.ACCOUNT.CREATE ();
Accountinfo Account = Dal. Signin (userid, password); // << ß ---- Take a look at the Iaccount interface above 4
You can directly call the interface method to operate the database through the lower DAL layer (in this specifically for user account related operations), and the BLL layer doesn't know how to access the database through SQLSERVERDAL or ORACLDAL, this is determined by Dal Factory, what are you using? Database and underlying details, do not know if BLL knows that the benefits of this is that the BLL layer and the upper program will not or a little rash due to the underlying program changes, because the interface is called in the BL, as long as the interface is defined Change, everything is still OK.
6 Petshop.configtool
First, there is an app.config file in ../microsoft/petshop/configtool/, look at the content, define two database connection strings, there is a line in app.config
Public static readonly string configfile = configurationSettings.appsettings ["WebConfigFileLocation"];
Then statement
XmLDocument Doc = New XmLDocument ();
Doc.Load (configfile);
Load the web.config file, and finally write the encrypted connection string into the XML node corresponding to Web.config. For ASP.NET applications. Where encryption is still using Petshop.Utility.
Configconsole, call PETSHOPConnectionstring class EncryptConnectionstring executes encryption of the coupling string. In addition, the PETSHOPEVENTLOG class is also used in ConfigConsole. Used to record program logs.
Therefore, the connection string of web.config is encrypted at the last deployment.
7 PetShop.Model business entity model
The following is the procedure of the AccountInfo class:
Namespace petshop.model {
///
/// Business Entity Used to Model Accounts
/// summary>
[Serializable]
Public class accountinfo {
// Internal MEMBER VARIABLES
Private string _userid;
PRIVATE STRING _PASSWORD;
Private string_email;
Private addressinfo _address;
Private string _language;
PRIVATE STRING_CATEGORY
Private bool _showfavorites;
Private bool _showbanne;
Public Accountinfo () {
}
Public AccountInfo (String Userid, String Password, String Email, AddressInfo Address, String Language, String Category, Bool Showfavorites, Bool Showbanners) {
THIS._USERID = UserId;
THIS._PASSWORD = Password;
THIS._EMAIL = Email;
THIS._ADDRESS = Address;
THIS._LANGUAGE = Language;
THIS._CATEGORY = CATEGORY;
THIS._SHOWFAVORITES = ShowFavorites;
THIS._SHOWBANNERS = Showbanne;
}
// Properties
Public String UserId {
Get {return _userid;}
}
Public String Password {
Get {return _password;
}
Public String email {
Get {return_email;}
}
Public addressinfo address {
Get {return _address;
}
Public string language {
Get {return_language;
}
Public string category {
Get {return _category;
}
Public bool isshowfavorites {
Get {return _showfavorites;}
}
Public bool isshowbanners {
Get {return _showbanners;
}
}
}
This originally wants to analyze the BLL layer, but these models are used in SQLServerdal and Oracles, no matter how, the upper program performs the final result to operate the database, and the database is a relational, not object-oriented, then To abstract the plane's 'table' combine business rules to abstract class, so that the upper layer (BLL and above) think that it is self-operated rather than the database table, so that the 'they' feel that there is no database, and the upper layer is object-oriented Programming is. I want to do what's the purpose of or-mapping now (just guessing, hope is like this, please point out). We have seen in step 2 above, define the SQL statement in SQLServerdal and ORACLEDAL in PETSHOP, and then call this SQL statement as a parameter according to the upper layer call, and finally executed in SQLHELPER. Take a closer look at the SQL ServerDal program, you will find the following program: Private void setaccountparameters (Sqlparameter [] PARMS, AccountInfo ACC) {
PARMS [0] .value = acc.email;
PARMS [1] .value = acc.address.firstname;
PARMS [2] .value = acc.address.lastname
PARMS [3] .value = acc.address.address1;
PARMS [4] .value = acc.address.address2;
PARMS [5] .value = acc.address.city;
PARMS [6] .value = acc.address.state;
PARMS [7] .value = acc.address.zip;
PARMS [8] .value = Acc.address.country;
PARMS [9] .value = acc.address.Phone;
PARMS [10] .value = acc.userid;
}
PARMS [X] is the parameters in the parametric SQL statement that is declared as a constant, where the field of AccountInfo in Model and these parameters mapping. So for the BLL layer, you only know these models, anyway, finally in SQLServerdal or OracleDal will mapping to the parameter to access the database (why not directly mapping to the field of data sets? I think it should be Because the database operation here is directly for SQLHEPER, it is not necessary to use SQLHELPER. So the XXX DAAB layer in the figure, so mapping is sent to the parameters to DAAB)
Data Access Layer Summary:
DAL Completes the database access task, the upper layer (BLL) is required to call the interface, do not need to know the specific access details, do not know what kind of database and database tables, etc., which is implemented in the Factory mode and the second method of the above. .
2003-9-19
Cocoboy79