Architecture | Design System Adoption | b/s structure, divided into three layers, respectively, data access layer, business rules layer, web appearance layer. They each have their own responsibilities, separate and coordinate with each other to form a whole functional system of software, the responsibility of the data access layer is responsible for the access to the data source (where the data source refers to SQL Server 2000), the Business Rules layer is responsible for the data in accordance with business processes, The web façade layer is responsible for providing an interface to the user to interact with, and is responsible for input and output data only. This design is very common, it provides a better maintenance of the system.
Design:
1) Data Access layer:
Many people would like to encapsulate a large number of SQL scripts at this level to simplify the design of the upper layer, but such a design is not appropriate! Business in general will change, if the SQL script "hard-coded" together, modify the source code to modify the program. And the user there is usually only packaged binary program! So it's a good idea to put a script that operates on the data outside, usually near the data, like SQL Server, where we
Written as stored procedures on the SQL Server server. There are two benefits to writing stored procedures: first, when the business changes, just change the stored procedure. Second, there is no need to transfer a large number of scripts over the network to the database server to resolve the implementation of the network to bring a great burden. Instead, it simply calls a stored procedure name, which greatly reduces the burden on the network and the middle tier. Such as: Perform an action to add a user
Create PROCEDURE dbo. User_create
@RealName varchar (50),
@DeptName varchar (50),
@HashedPassWord varchar (50),
@Tel varchar (50),
@Address varchar (50),
@DutyName varchar (50),
@UserName varchar (50)
As
BEGIN Tran
insert INTO [User] (Username,realname,deptname,hashedpassword,tel,address,dutyname) VALUES (@UserName, @RealName, @ Deptname, @HashedPassWord, @Tel, @Address, @DutyName)
If @ @error!=0
Begin
Rollback
return 0
End
Else
Begin
Commit
Return 1
End
Methods for executing stored procedures and maintenance and database connection states (such as Execsql (string SQL), Open ()) should be encapsulated in a common class by other classes, rather than each class having its own database Method! This intention is to reduce the duplication of reliance, and if the method of sharing this class is abstracted into an interface, so that all the classes that use it use this interface, the class that uses it does not know these changes when the shared class changes, and reducing dependency means better adapting to the change!
Such as:
public class database:idisposable, Isqldatabase (reference to Codeplus)
{
Private SqlConnection con;
Private Dbconfig m_config=dbconfig.instance;
public int Runproc (string procname)
{
SqlCommand cmd = CreateCommand (procname, NULL);
Cmd. ExecuteNonQuery ();
This. Close ();
return (int) cmd. parameters["ReturnValue"]. Value;
}
public int Runproc (string procname, sqlparameter[] prams)
{
SqlCommand cmd = CreateCommand (procname, prams);
Cmd. ExecuteNonQuery ();
This. Close ();
return (int) cmd. parameters["ReturnValue"]. Value;
}
.......
}
Interface:
public interface Isqldatabase
{
int Runproc (string procname);
int Runproc (string procname, sqlparameter[] prams);
void Runproc (String procname, out SqlDataReader dataReader);
void RunCommand (String command,out SqlDataReader dataReader);
void Runproc (String procname, sqlparameter[] prams, out SqlDataReader dataReader);
SqlCommand CreateCommand (String procname, sqlparameter[] prams);
void Open ();
void Close ();
SqlParameter Makeinparam (String paramname, SqlDbType DbType, int Size, object Value);
SqlParameter Makeoutparam (String paramname, SqlDbType DbType, int Size);
SqlParameter Makeparam (String paramname, SqlDbType DbType, Int32 Size, ParameterDirection Direction, Object Value);
}
For connection information, such as the connection string should not appear in all the places used in the database, be responsible for the deployment of all classes in the adjustment! So it's wise to put it in an XML configuration file (into integration and mixed security) and then manage it with a single class.
The contents of the XML file:
<?xml version= "1.0" standalone= "yes"?>
<NewDataSet>
<DBConfig>
<ServerName>Gaolei</ServerName>
<Machine>GAOLEI</Machine>
<DataBase>OA</DataBase>
</DBConfig>
<DBConfig>
<ServerName>Gaolei</ServerName>
<UID>sa</UID>
<PWD></PWD>
<Machine>Gaolei</Machine>
<DataBase>OA</DataBase>
</DBConfig>
<DBConfig>
<LogCount>100</LogCount>
</DBConfig>
</NewDataSet>.
For the data entity layer, it is responsible for passing data, which is where each layer exchanges data. The design should consider such factors as:
First: Performance, the exchange of data places must require fast exchange, accounting for less memory.
Second: Business rule classes can use them effectively.
Third: It is beneficial to use them in the interface, that is, to be able to bind with the user control to help simplify the development of the interface.
In order to satisfy the first requirement, the domain of the entity can be moved up in the base class, so that the two classes are inherited and each negative. The number of instances of a base class (numeric Class) is disproportionate to the number of instances of its subclass (method Class), and the base class instance is always larger than the number of method instances, typically n:1, eliminating the unnecessary memory overhead and greatly improving performance. For some method argument lists that are too long, you can use the base class object instead.
Method classes integrate commonly used data processing methods, so once the business rule class uses it, it can greatly simplify the complexity of the rule class, and designers can concentrate on designing rule classes without having to consider the problem of entity classes at the same time. The controls on the interface will naturally support binding on these properties because the range is moved up and the domain is made into attributes. (Attributes of. NET controls)
Entity classes:
(Numeric Class)
public class Logrow:marshalbyrefobject,icomparable
{
protected String M_operatetype;
Public virtual String Operatetype
{
get {return m_operatetype;}
set {M_operatetype=value;}
}
..........
Public Logrow ()
{//TODO: Add constructor logic here
}
#region IComparable Members
public int CompareTo (object obj)
{
Logrow row= (logrow) obj;
If Row.Operator.Equals (this. Operator) &&row.operatetype.equals (this. Operatetype) &&row.operatetime.equals (this. Operatetime) &&row.contents.equals (this. Contents))
return 1;
return 0;
}
#endregion
}
Method class:
public class Log:logrow
{
Public Log ()
{
}
public bool Create (String operatetype,string contents,string operator,system.datetime operatetime)
{
Database data = new database ();
Sqlparameter[] Prams = {
Data. Makeinparam ("@OperateType", System.data.sqldbtype.varchar,50,operatetype),
Data. Makeinparam ("@Contents", system.data.sqldbtype.varchar,255,contents),
Data. Makeinparam ("@Operator", System.data.sqldbtype.varchar,50,operator),
Data. Makeinparam ("@OperateTime", System.data.sqldbtype.datetime,8,operatetime)
};
int reval = data. Runproc ("Log_create", prams);
Data. Close ();
Data. Dispose ();
if (reval==1)
{
return true;
}
Else
{
return false;
}
}
public bool Create (Logrow logobject)
{
return this. Create (Logobject.operatetype,logobject.contents,logobject.operator,logobject.operatetime);
}
public bool Delete (System.DateTime operatetime)
{
Database data = new database ();
Sqlparameter[] Prams = {
Data. Makeinparam ("@OperateTime", System.data.sqldbtype.datetime,8,operatetime)
};
int reval = data. Runproc ("Log_delete", prams);
Data. Close ();
Data. Dispose ();
if (reval==1)
{
return true;
}
Else
{
return false;
}
}
.......
}
2) Business Return layer:
To have your own independent custom exception classes, use multithreading to improve performance for business methods. It is best to use teampletemothed mode to integrate processes and adapt to future business changes or to set methods to virtual!
public class Ommanager
{
private user user;
Private Userrole userrole;
private role role;
Private Rolepopedom Rolepopedom;
private string M_currentusername;
private string M_currentpassword;
Public Ommanager (String currentusername,string currentuserencryptedpassword)
{
User=new User ();
Userrole=new userrole ();
role=new role ();
Rolepopedom=new Rolepopedom ();
if (new Securityvalidate ()). Validator (Currentusername,currentuserencryptedpassword))
{
This.m_currentusername=currentusername;
This.m_currentpassword=currentuserencryptedpassword;
}
Else
{
throw new SecurityException ("Invalid username/password");
}
}
Public virtual string NewUser (Userrow newuserdata, string[] assignedroles)
{
String M_hashedpassword=stringencryptor.encryptor (Newuserdata.hashedpassword);
Newuserdata.hashedpassword=m_hashedpassword;
if (user. Create (Newuserdata) &&userrole.create (newuserdata.username,assignedroles))
{
Todosomething
}
return null;
}
........}
3 Web Interface layer: To use the rules layer method to perform business functions, but not everything goes through the rules layer, but the data requires the business process to refer to the rules layer method, if the business does not need processing (such as: Populating a drop-down list) can directly use the data access layer, which can reduce unnecessary performance costs. For security, the use of rule classes must be validated. For performance, you can use ASP.net cache technology to resolve
