C # -- Dependency Interface Programming and simple factory

C # -- Dependency Interface Programming and simple factory
When developing a project, you may encounter such a problem: when the project is half developed, the original Access to the database is ADO. NET, the Project Manager suddenly asked to use the EF entity model to access the database ...... er, okay! In this case, we need to modify the original code. We all know that it is in ADO. net, the data access layer DAL is coupled with the business logic layer, when the data access layer code from the original use ADO. NET to access the database to use the EF entity model to access the database, the business logic layer BLL Code also needs to change accordingly (this is a very painful thing)

1 // private UserEFDAL userefDal = new UserEFDAL (); // create an instance when the project uses EF to access the database. 2 3 // private UserInfoDAL userDal = new UserInfoDAL (); // create an instance when the project uses ADO to access the database. // However, when the database access method changes, the BLL layer must be changed accordingly and it cannot be guaranteed that the nwe Instance name will be the same after the change. 5 // This is quite a tragedy, and 6 public User Add (User userInfo) 7 {8 return userDal. EFAdd (userInfo); // when the instance names are different from each other in the two methods, it is sad .... 9 10 // return userefDal. ADOAdd (userInfo); 11}

 

Through the simple code above, we can find that when we want to switch the database access mode, we need to constantly change the name of the new instance, the added method defined in EF is EFAdd, and the added method defined in ADO is ADOAdd, so that the project for modifying code is very large (when you finish the modification, it is estimated that you have also been fired), and we hope that when the data access method is not used, The BLL Layer Code will be rarely changed, or you can switch the database access mode without changing the BLL-layer code. We hope that the internal methods will not change when the data access mode is different, we stipulate that the method added in ADO or EF is Add, and the modification method is Edit. Speaking of this, we must understand what we are going to talk about next. That's right, it's an interface. What is an interface in C? The so-called interface is actually a kind of specification, so that the classes or structures that implement the interface are consistent in form. When a class inherits the interface, it must implement all the members of the interface, using Interfaces can make the program clearer and more organized, which is the benefit of interfaces. Therefore, in the above example, we can define an interface so that EFDAL and ADODAL can inherit this interface.

// Define an interface when using ADO.. NET accesses the database or when the EF entity model accesses the database, it inherits from this interface public interface IDALInterface {// multiple Member User Add (User userInfo) can be defined here );} // The EFDAL inherits the IDALInterface public class UserEFDAL: IDALInterface {DataModelContainer db = new DataModelContainer (); public User Add (User userInfo) {db. user. addObject (userInfo); db. saveChanges (); return userInfo;} public class UserInfoDAL: IDALInterface // ADO. NET inherits the IDALInterface interface {// <summary> /// implements the IDALInterface interface /// </summary> /// <param name = "userInfo"> </ param> // <returns> </returns> public User Add (User userInfo) {// here, execute the Add operation and return the inserted entity return userInfo ;}}

 

 

// BLL Layer Code IDALInterface userDal = new UserEFDAL (); // here, because the DAL of EF and the DAL of ADo are inherited from IDALInterface // when the way to access the database changes, you only need to change the database access instance. In this way, the amount of code changes reduced: public User Add (User userInfo) {return userDal. Add (userInfo); // return userefDal. Add (userInfo );}

 

Through the above example, we can see that as long as the BLL layer changes different new instances without changing too much BLL code, you can switch between different data access methods, of course, you still need to modify the code at the BLL layer. We still need to find IDALInterface userDal = new UserEFDAL (); one by one, and then modify it, is there a way to change the access methods of different databases without modifying the BLL-layer code. We can create a factory and create an instance through reflection.

/// <Summary> /// create a simple factory to obtain the corresponding assembly, /// </summary> /// <returns> </returns> public static IDALInterface GetDALStyle () {string assemblyName = ConfigurationManager. appSettings ["assemblyName"]; // configure the database access mode through the configuration file string typeName = ConfigurationManager. appSettings ["typeName"]; // creates an instance return Assembly through reflection. load (assemblyName ). createInstance (typeName) as IDALInterface ;}

 

The corresponding BLL code is changed

IDALInterface userDal = DALSimpleFactory. getDALStyle (); // create an instance public User Add (User userInfo) {return userDal through the factory. add (userInfo); // return userefDal. add (userInfo );}

 

At this point, we only need to modify the corresponding configuration in the configuration file to switch the access methods of different databases without modifying too much code, the development cycle of the project is greatly reduced. The coupling between the BLL layer and the DAL layer can be greatly reduced through factory instances, that is, decoupling.