A recent study of a Web architecture solution suitable for team development, which is suitable for division and collaboration and has a certain scalability, suitable for different database needs, so I looked up some information, the initial concept of a set of structure, please advise you a lot.
The origin of the problem
A recent study of a Web architecture solution suitable for team development, which is suitable for division and collaboration and has a certain scalability, suitable for different database needs, so I looked up some information, the initial concept of a set of structure, please advise you a lot.
Explore
The most classic Web development architecture is the three-tier architecture, the presentation layer, the logical layer, and the data processing layer.
Data Access layer: Its function is primarily to be responsible for database access.
Business Logic Layer: The core of the entire system, it is related to the business (domain) of the system.
Presentation layer: The UI part of the system that is responsible for the interaction of the user with the entire system. The ideal state is that the presentation layer should not include the system's business logic.
These are classic explanations, and if you want to adapt to different databases, you need to join the factory model, which uses an interface-oriented way to make polymorphic calls. Is this a bit like petshop? So the initial idea of the architecture is this:
For example, take a look at the user information, and briefly describe the process of the architecture: (The following is a classic approach like PetShop, you can skip it)
Step 1 , first we should build the entity model that the project needs, in here New user information entity pattern, UserInfo.cs. This class is saved in the model project.
Step 2 , we will write the unit function of the project to the relevant interface, here to obtain the user information function as an example. Create a new Iuser interface in the Idal project.
Get user information based on user ID
UserInfo Getuserbyid (int userId);
Step 3, complete the interface, we will implement it, now we use SQL Server,Oracle Two database access methods to implement it. The following is the reality of the user class pair interface in Sqlserverdal:
public class User:iuser
{
Public UserInfo Getuserbyid (int userId)
{
Implementation action
}
}
Oracledal in the real way ....
Step 4, this database access layer should be basically written, the following should be called to the logical layer, but two ways to implement how to call it, or how to choose to call it, PetShop is handled in the dalfactory of the DataAccess class , using reflection to load an assembly to instantiate the required classes:
private static readonly string path = configurationmanager.appsettings["Webdal"];
public static Iuser CreateUser ()
{
String className = Path + ". User ";
Return (Iuser) assembly.load (path). CreateInstance (ClassName);
}
As to which database access layer to choose, configure the Webdal in the configuration file. such as: <add key= "Webdal" value= "Sqlserverdal"/>.
In this way, the coupling between the logical layer and the data access layer is basically solved.
Step 5, the following should write the logic layer, in the BLL inside the creation of User.cs class. Roughly as follows:
public class User
{
private static readonly Iuser dal = DALFactory.DataAccess.CreateUser ();
Public UserInfo getuserinfo (int userId) {
Return DAL. Getuserbyid (USERID);
}
}
It doesn't feel BLL meaningless because it's just a simple call to the data access layer method, but it's not, there's only one simple case where a BLL in a real project can be a very complex logic, and the result of this complex logic is presented to the presentation layer.
Step 6, the last is the presentation layer, as if there is nothing to say, the data from the BLL to bind to your page on the line.
The above is imitation petshop architecture design , it seems that there is no doubt about the place, after all, is Microsoft's classic case. You may complain about the place there are two points, one is not a bit more, the relationship is too complex; two if I need to change or add a database field, that's not going to be painful because you want to edit the section. These two problems, I can not solve, one if said too much and cumbersome, then I write the following seems more complex, forgive .... Second, I think that all layered development, as long as the database field based on the establishment of the entity model, there will be the problem of joint modification. Unless you use all the DataTable, it is no doubt that the BLL, the presentation layer call, does not know what the DataTable contains, which makes it more convenient to call. To reduce the problem of joint modification, please advise if there is a solution.
Changes to the above schema
I have analyzed the design part of the data access factory of the above architecture, that is, the DataAccess class in Dalfactory. In this class, a call to a different database access layer is implemented
。 But if there is a project that has SQL Server and Oracle in it, do we have to do this:
private static readonly string path = configurationmanager.appsettings["Webdal"];//call to SQL Server database access layer
private static readonly string path2 = configurationmanager.appsettings["WebDAL2"];//call to the Oracel database access layer
public static Iuser CreateUser ()
{
String className = Path + ". User ";
Return (Iuser) assembly.load (path). CreateInstance (ClassName);
}
public static Iorder Createorder ()
{
String className = path2 + ". Order ";
Return (Iuser) Assembly.Load (path2). CreateInstance (ClassName);
}
If you want to create additional access classes, we'll also write Createproduct (), Createarticle,createmenu ... So this kind of class will be very cumbersome, we can not
Just one way to do it, and the rest of the work only needs to be done by the developer through the configuration file. There are two solutions for my solution:
First, Spring.net
This thing is specifically designed to decouple, we load its associated assembly into Dalfactory, so in dataaccess we can do the following:
private static readonly String Configpath = HttpContext.Current.Request.PhysicalApplicationPath +
configurationmanager.appsettings["Objectconfig"];//This is the physical location of the Spring.net object configuration file on the server
public static T createobject<t> ()
{
Iresource rs = new Filesystemresource (Configpath);
Iobjectfactory factory = new Xmlobjectfactory (RS);
String id = typeof (T). FullName;
Return (T) factory. GetObject (ID);
}
Here we pass in a generic that lets spring.net find the type of assembly in its object configuration file and load it, creating the corresponding object. Objectconfig file
Roughly as follows:
<?xml version= "1.0" encoding= "Utf-8"?>
<objects xmlns= "Http://www.springframework.net"
Xmlns:xsi= "Http://www.w3.org/2001/XMLSchema-instance"
Xsi:schemalocation= "Http://www.springframework.net
Http://www.springframework.net/xsd/spring-objects.xsd ">
<object id= "Idal. Iuser "type=" Sqlserverdal.function "></object>
</objects>
That's how it's called in BLL.
private static readonly Iuser dal = etouraf.shared.dalfactory.dataaccess.createobject<iuser> ();
This allows developers to add an associated configuration to the Object-config if they want to join an object. Hey, this becomes a petshop+spring.net, yy no limit ....
Second, also with reflection
Here we just use a key-value pair, as usual in the configuration file to configure the corresponding interfaces and objects, but we have to configure him in the web.config:
<add key= "Idal. Iuser "value=" Sqlserverdal.function "/>
In DataAccess, we write this:
public static T createobject<t> ()
{
String interfacefullname = typeof (T). FullName;
String className = Configurationmanager.appsettings[interfacefullname];
String nameSpace = classname.substring (0, Classname.lastindexof ("."));
Return (T) Assembly.Load (nameSpace). CreateInstance (ClassName);
}
Someone might say
String nameSpace = classname.substring (0, Classname.lastindexof ("."));
This interception is not a bit hard here, I only think of it now, but there is absolutely no problem.
Well, these are probably the two days of some harvest, please advise.