A generic application of the ASP three-tier architecture

When it comes to the three-tier architecture, I think we all know, here is simply said, the ASP. NET three layer architecture generally includes: UI layer, Dal layer, the BLL layer, each layer is passed by the model entity class, so model is one of the three layer architecture, exception for the database migration or more oo point, The Idal interface is derived from the DAL layer. Model is a simple corresponding database inside the class, the DAL layer is the main operation of the database method, the BLL this is to see the business. And the DAL layer most of the methods are almost, just a few insert,update,delete,select.

And then the generics, This is the beginning of 2.0.2.0 is a very important technology, about the advantages of generics have not said, a lot of online, in fact, said there is no use, everyone in the practice of the use of know, I think the most central place is the generic type, generic encapsulation of types, the definition of the type is deferred to the client, generics and like a type Template, as long as you define a generic class, it is equivalent to defining n classes, each of which has a different type.

As we said above, the DAL layer in the three-tier architecture typically includes insert,update,delete,select, so what our programmer brothers did before the generics arrived, first defining a DAL interface for each entity, For example, there is a user this entity object, then there is a iuserdal this interface and userdal this implementation class, if there are n entities, then almost requires N interfaces and implementation classes, and these interfaces of Insert,update,delete, The method signature of select is similar, the only difference being the type of the method parameter and the return value, let's look at the basic interface definition

public interface Iuserdal
{
int Insert (User model);
int Update (User model);
int Delete (int id);
User Getmodel (int id);
DataTable GetList ();
}

So in a project, like this interface definition is everywhere, most of it is repeated, although we have a hard-to-do code generation tool for our service, but from the design point of view or stand in the perspective of new technology, the code is very elegant, very uncomfortable, I think you feel the same way, oh O (∩_∩) o~.

When generics come, we finally can not see so many of the definition of duplicate interface, finally can take a breath, then the generic is how to implement it, before we realize we have no generic iuserdal definition, where the Insert,update method is a user parameter, Similar to the other interface is a parameter, but the type is not user, may be order, or other, in view of the Getmodel return value type is User,getlist is also the same, but here we use a DataTable this universal type to replace, But we all know that this type of DataTable is a weak type, and when the UI layer is called, I don't know what the field is in this DataTable, which brings some trouble in the development period.

The implementation of the generic is finally playing, it is very simple, is not a pair of angle brackets, yes, as long as the iuserdal behind the angle bracket, the inside with a character instead of the type can be, oh, to add a generic constraint, is a where, that is, the generic type can only be a reference type, Cannot be a value type, is your model A value type?? It's impossible, I don't believe it anyway. Then the definition of this generic interface is:

public interface idal<t> where T:class
{
int Insert (T model);
int Update (T model);
int Delete (int id);
T Getmodel (int id);
Ilist<t> GetList ();
}

Oh, so simple is to add a T to the previous user type to "change" on it, I did not think of it, whining, then in userdal this inheritance class can be clearly defined that generic type, because I this class is used to implement the user this entity class (or database table bar) , here, Userdal we call Iuserdal's client. The code is as follows:

public class Userdal:idal<user>
{
#region Idal<user> Members

public int Insert (User model)
{
Coding
}

public int Update (User model)
{
Coding
}

public int Delete (object ID)
{
Coding
}

Public User Getmodel (object ID)
{
Coding
}

Public ilist<user> GetList ()
{
Coding
}

#endregion
}

Well, we liberated the Dal and idal, so the BLL layer can be used generics, of course.

We first say, without the implementation of the generic BLL layer, here does not consider the business of the BLL, then the BLL is a simple call to the DAL database operation method, that is, the Iuserdal interface definition method, the general USERBLL code is as follows:

public class USERBLL
{
Private Iuserdal dal = new Userdal ();

public int Insert (User model)
{
Return DAL. Insert (model);
}

public int Update (User model)
{
Return DAL. Update (model);
}
public int Delete (int id)
{
Return DAL. Delete (ID);
}
Public T getmodel (int id)
{
Return DAL. Getmodel (ID);
}
Public DataTable GetList ()
{
Return DAL. GetList ();
}
}

I think this is the simplest BLL code, and most of the small projects This is enough, because there is no business, but if you want to such a code every BLL is so Xie, a project dozens of hundreds also such a portrait will be exhausted, code tools, although can be solved, But when we see so many duplicate code, similar code, really heartache, do not you feel heartache, if you do not feel or do not want to change the words or later still write repetitive code, with code tools to do, I think you will not how to improve your code ability, nonsense.

So with generics, we can define a base class for all of the BLL, the other class as long as the inheritance, slightly according to the business of the different point of business code can be, or even do not inherit, we first look at the implementation of the Code, this line of code is the best way to talk, see the following code:

public class Basebll<t, d>
where T:class
where D:idal<t>,new ()
{
Private D dal = new D ();

public virtual int Insert (T model)
{
Return DAL. Insert (model);
}

public virtual int Update (T model)
{
Return DAL. Update (model);
}
public virtual int Delete (object ID)
{
Return DAL. Delete (ID);
}
Public virtual T Getmodel (object ID)
{
Return DAL. Getmodel (ID);
}
Public virtual ilist<t> GetList ()
{
Return DAL. GetList (model);
}
}

This also simple, that is, the entity class to T, the Idal interface to D, and define D this type of constraint, that is, my d must be a realization of idal<t> this interface, and idal angle brackets inside the t is BASEBLL inside T, see here, I believe everyone should understand, if you want to achieve USERBLL, you can inherit BASEBLL this base class, here is why the BASEBLL method is defined as virtual, the reason is very simple, because your BLL layer of other classes can not have no business, It is impossible to simply call the Dal method, the other BLL class can be based on the business to override the relevant method, userbll the corresponding code as follows:

public class Userbll:basebll<user, userdal>
{

}

If USERBLL does not have any business, then do not inherit, in the UI directly with BASEBLL this generic class can be, the invocation is very simple

Basebll<user> dal=new basebll<user> (); that's it.

A generic application of the ASP three-tier architecture