ASP. net mvc + EF framework + EasyUI permission management series (3)-interface-Oriented Programming

1. Create a class library for Interface Programming

(1) In this blog, we mainly program interfaces. Since interfaces are oriented, we must create a class library for storing interfaces and then create several interfaces, next I will detail the process of creating this interface class library and interface class.

(2) First, create a class library in the database access interface layer under this project, and name it LYZJ. userLimitMVC. IDAL, And then we create three interface classes, which are IBaseRepository. cs, IUserInfoRepository, IRoleRepository. Some people may feel confused, so I will put the project graphics here for your convenience ,:

(3) Next we will analyze in detail the functions implemented by the three interface classes under the LYZJ. UserLimitMVC. IDAL class library.

2. Analysis of Three interface classes in the LYZJ. UserLimitMVC. IDAL class library

(1) IBaseRepository: In this basic interface, we encapsulate all database operation methods. from another perspective, interfaces are a constraint, the interface we define limits the methods used to operate the database. In the following example, each database entity (UserInfo, RoleInfo) needs to operate the database interface, therefore, I have defined a base interface to encapsulate database access methods. Then, the database entity only needs to inherit from this base interface. The Code is as follows:

1 public interface IBaseRepository <T> where T: class, new ()
2
3 {
4
5 // Add database and reference EF framework
6
7 T AddEntity (T entity );
8
10
11 // modify the database
12
13 bool UpdateEntity (T entity );
14
15
16
17 // Delete the database
18
19 bool DeleteEntity (T entity );
20
21
22
23 // query the database-simple query
24
25 IQueryable <T> LoadEntities (Func <T, bool> wherelamties );
26
27
28
29 /// <summary>
30
31 // implement paging query of data
32
33 /// </summary>
34
35 // <typeparam name = "S"> sort by class </typeparam>
36
37 // <param name = "pageIndex"> current page </param>
38
39 // <param name = "pageSize"> How many data entries are displayed on a page </param>
40
41 // <param name = "total"> total number of entries </param>
42
43 // <param name = "whereLambda"> obtain the sorting condition </param>
44
45 // <param name = "isAsc"> sort by reverse or ascending order </param>
46
47 // <param name = "orderByLambda"> sort by the field </param>
48
49 // <returns> </returns>
50
51 IQueryable <T> LoadPageEntities <S> (int pageIndex, int pageSize, out int total, Func <T, bool> wherelamties, bool isAsc, Func <T, S> orderByLambda );
52
53} (2) IUserInfoRepository. This interface only needs to inherit from the base interface. When inheriting the base interface, it implements all the methods in the base interface. The Code is as follows:

1 public interface IUserInfoRepository: IBaseRepository <UserInfo>
3 {
4
5} (3) IRoleRepository, as explained in (2), the Code is as follows:

1 public interface IRoleRepository: IBaseRepository <Role>
2
3 {
4
5} (4) Note: When we operate IUserInfoRepository and IRoleRepository, we need to add a reference to LYZJ. UserLimitMVC. Model, because we need to use database entity objects.

3. Redesign of the database access layer (LYZJ. UserLimitMVC. DAL Class Library)

(1) RoleRepository Design

When we complete the data access interface layer, we need to re-Modify the data at the database access layer because the database access interface layer is used, so we need to add the DLL at the database interface layer, LYZJ. userLimitMVC. IDAL.

Then, the role warehouse inherits the role warehouse interface at the database access interface layer. The Code is as follows:

1 public class RoleRepository: BaseRepository <Role>, IRoleRepository
2
3 {
4
5} (2) Design of the user warehouse (RoleRepository), as described above, the Code is as follows:

1 public class UserInfoRepository: BaseRepository <UserInfo>, IUserInfoRepository
2
3 {
4
5} (3) the design idea of the database access layer is: Inherit the base class first and implement the interface. The above implementation refers to this sentence.

Note: The database access layer is mentioned here. If you do not know anything or do not know anything, you can leave a message and I will reply immediately, next we will start to study the implementation of the business logic layer.

4. business logic layer (BLL)

(1) from the beginning to the present, our database access layer can only be said to be a little bit slow, because we will modify the database access layer later, the code we write is not always the same, but as we write slowly, we will extract a lot of things for encapsulation, so if you read my blog carefully, I have been modifying the code.

(2) What is the business logic layer? I believe that all users who have worked on the asp.net layer-3 architecture understand the encapsulation of the database access layer. Here I will not explain in detail what the business logic layer is, if you do not understand it, you can search Baidu or Google.

(3) Next we start to operate on the business logic layer.

5. Implementation of the business logic layer (LYZJ. UserLimitMVC. BLL)

(1) first, we create a UserInfoService class, which is to implement the business logic of UserInfo (add, delete, modify, and query ).

(2) if we want to implement the business logic layer, we need to add the database access layer and real layer as well as the DLL that operates the Entity FrameWork, as follows: LYZJ. userLimitMVC. DAL, LYZJ. userLimitMVC. IDAL, LYZJ. userLimitMVC. model, System. data. entity.

6. Implementation of the UserInfo business logic class

(1) First I paste the code of the UserInfo. cs class. Here we will carefully analyze the implementation of the code of the UserInfo class:

1 namespace LYZJ. UserLimitMVC. BLL
2
3 {
4
5 /// <summary>
6
7 // UserInfo business logic
8
9 /// </summary>
10
11 public class UserInfoService
12
13 {
14
15 // access the DAL to implement CRUD
16
17 // private DAL. UserInfoRepository _ userInfoRepository = new UserInfoRepository ();
18
19 private IUserInfoRepository _ userInfoRepository = new UserInfoRepository ();
20
21
22 public UserInfo AddUserInfo (UserInfo userInfo)
23
24 {
25
26 return _ userInfoRepository. AddEntity (userInfo );
27
28}
29
30
31 public bool UpdateUserInfo (UserInfo userInfo)
32
33 {
34
35 return _ userInfoRepository. UpdateEntity (userInfo );
36
37}
38
39}
40
41} (2) because our business logic layer uses Entity objects, that is, UserInfo, we need to add references here, which I have mentioned above. The business logic layer is to access the database access layer (DAL) and then add, delete, modify, and query the database. Therefore, we need to define a database access layer instance: private DAL. userInfoRepository _ userInfoRepository = new UserInfoRepository, now that we have an interface, we can rely on the Interface Definition: private IUserInfoRepository _ userInfoRepository = new UserInfoRepository ();. Where are the differences between the two methods? What are their differences? Let me give a general idea:

(3) What are the differences between the above two definitions?

Some people may think that there is no difference between the two writing methods above. Otherwise, there is a great difference in writing such statements. If we have many methods below, all our methods need to call the methods in the warehouse, but this warehouse is an interface instance, which has nothing to do with the specific implementation, that is to say, the data access layer interface that our business logic layer depends on will not change as long as the interface does not change. If we need to use ADO to implement this function one day, we only need to replace the UserInfo warehouse after new with ADO. in this case, the following methods do not need to be changed. This is called dependency interface programming. As long as the interface does not change, the following code will never change.

7. Do not want new UserInfoRepository (); warehouse. What should I do?

(1) the previously defined interface has been used to instantiate the programming of the dependent interface, but now I do not want the new UserInfoRepository (); instance, because this object is very likely to change, it is possible to use EF for warehousing, or ADO for warehousing, and we need to define storage objects for instances designed to the business logic layer. When there are many entities, it is very inconvenient to maintain. We need to modify these items on every page, so here we can think about how to pass this storage as a parameter, we only need to maintain it in the class that passes the parameter. Next we will analyze how to use it.

(2) when there are changes, we need to find a way to encapsulate them. Here, of course, we can. We will put the method for obtaining this warehouse instance in a public place, you just need to change the public place when you change it. How can this problem be solved? The simplest thing we think of first is a simple factory. What is a simple factory? In fact, it is very simple. We only need to understand that as long as it is a factory, it is the class for creating instances for us. Since we need a public place here, we need to go to LYZJ. userLimitMVC. add a RepositoryFactory class under the DAL class library. In this class, we have created a UserInfoRepository attribute. In this static attribute, we can return this warehousing for us. At this time, if we want to modify it, We can directly change the UserInfoRepository attribute.

(3) implementation of the RepositoryFactory class

(1) With the above analysis, the code for implementing this class is as follows:

1 namespace LYZJ. UserLimitMVC. DAL
2
3 {
4
5 public static class RepositoryFactory
6
7 {
8
9 public static IUserInfoRepository UserInfoRepository
10
11 {
12
13 get {return new UserInfoRepository ();}
14
15}
16
17}
18
19} (2) then we modify the definition of the business logic layer to instantiate the repository Code as follows:

Private IUserInfoRepository _ userInfoRepository = RepositoryFactory. UserInfoRepository;

(3) At this time, we have completed the encapsulation of the Warehouse. If we want to replace the warehouse, we only need to replace the method in RepositoryFactory. This is a simple factory, after we add this simple factory, the dependency between the database access layer and the business logic layer reduces coupling.

8. Summary

(1) This blog is finally over. Now I know that it is really hard to write a blog for a project. It is not as convenient as writing a technical point for a language organization, I have been writing this article for five hours. However, it is hard to get the work done. If you don't understand anything, you can ask me, I uploaded the code of this blog to CSDN. You can download it, read the code, and read the blog. I think this is easy for everyone to understand.

(2) below is the current project architecture after writing this blog today