In my previous introduction to the hybrid development framework, the interface is based on the implementation of the WinForm, the background using the Web API, WCF services, and direct connection to the database in several ways of hybrid access, in Web projects we can also use this way to achieve hybrid access, although the Web API or WCF call, relatively direct connection to the database, the response is slightly less efficient, but strong scalability, but also can mobilize more device access, including mobile application access, website access, Winfrom Client access, which can make the service logic is relatively independent, responsible for providing interface. The most representative of this method is the wide application of the current Web API, which facilitates the rapid development and independent maintenance of each access terminal, and greatly improves the speed and efficiency of parallel development. In the enterprise, we can reasonably standardize the various business services of the Web API interface, each application access can be independently developed, can also be entrusted to the outsourcing team to develop.
1, WinForm Hybrid access Method review
From the outset, our web API was designed to provide access to a wide variety of applications, such as the need to access WinForm clients, app programs, website programs, applications, and so on, as the Web API layer acts as a common interface layer. We can guarantee the data consistency of each interface application layer.
This paper introduces various applications in the interface layer of the Web API, in general, our interface is to provide a variety of standard interfaces, as well as authentication of identity processing, and so on, in the Web API layer to consider the business scope of the relevant interface, and at each interface layer, consider how to the Web The API is further encapsulated for ease of invocation, although the mechanism of WinForm and Web invoke Web API is different, but we can still reuse the client wrapper layer of the Web API.
In the Winfrom interface call mixed access interface mode, it is shown below, the main idea is through a unified façade layer facade interface layer for service delivery, as well as client invocation of the encapsulation processing interface.
With the extensive use of the Web API layer, this approach offers great flexibility by encapsulating the base classes of each layer at the framework level, which greatly simplifies the required encoding and provides a unified, rich base interface for invocation.
Since WinForm invokes the Web API, the client makes a simple wrapper over the Web API layer, which simplifies the use of the Web API interface by invoking the wrapper class and passing in the relevant parameters to get the serialized object (both the base object and the custom class object).
This encapsulation method, because of the unified implementation of the base class, as well as the provision of URL address, parameter assembly and other processing, very conducive to WinForm interface background code to call, speed up the development of WINFOM interface function. For example, from the further refinement of the architecture diagram, we can see some of the base classes (green parts) of each layer.
On the Web API layer-based build, we provide the Web API service layer with Baseapicontroller and businesscontroller<b, T> 's Web API controller base class to encapsulate the normal business processing; API Service Call layer, we provide baseapiservice<t> base class to encapsulate the general interface;
At the same time provide ibaseservice<t> facade façade layer of the unified interface, and Callerfactory<t> call mode for WinForm background code for interface calls.
This encapsulation of the interface on the basis of the Web API can greatly simplify the invocation of the interface, but also can be provided to the web side of the backend controller, very easy to use, the following describes the implementation of hybrid access in Web projects.
2. Introduction to Web-hybrid access
Referring to WinForm hybrid access, we can also apply this approach to the web framework, with the specific hierarchical relationships shown below.
Integration of two very common access methods: Web API service access, direct connection to the database access, a very powerful feature, a fast access efficiency, each has its own application scenarios, we are in different business environment configuration, so that it adapt to our actual application can, under normal circumstances, We recommend using the Web API approach to build an ecosystem of entire business systems.
Web API interface calls can be done in two ways, one is the pure JS framework, similar to the Angularjs way, through its controller to make the relevant interface calls; there is another way Using the MVC method of ASP, the front-end interface through JS call back-end controller to achieve data processing, the specific logic has a backend logic controller for the Web API processing, we use the latter to achieve more flexible processing.
In contrast to WinForm, the hybrid access on the web is relatively complex, although the WinForm interface is similar to the view HTML code in Web MVC, WinForm The background logic code similar to the view of the Controller object, but it is really troublesome, It is equivalent to the processing interface that we also need in the context of the Web interface controller on the back of the wrapper.
Throughout the Web project based on hybrid access, the entire project is structured as follows for the use of the Web API interface.
With the illustration of these illustrations, we should have a general understanding of the overall, for further details, we may still not be too clear, need to be introduced in specific project code engineering.
1) for the database tier
We can consider a variety of database access support, such as SQL Server, Oracle, SQLite, access, or PostgreSQL support, these are based on relational database support, with good alternative and standard consistency.
They can be implemented by following a unified SQL or partially customized SQL statement, or through a stored procedure.
For the different support scheme of the database, I use the database access component of Enterprise Library to support the consistency, which can reduce the processing of different database models, unify the access of this kind of component, and realize different database access.
2) for the business logic layer
The business logic layer is a combination of several different layers for use. The core layer in the project, as shown below, includes the business logic layer BLL, the data Access layer Dal (different implementation tiers), the data access interface layer Idal, and the entity entities layer that passes the data.
These modules have standard base classes on each layer to enable the encapsulation of the docking port or function.
The following are the inheritance relationships of the BLL layer
/// <summary> /// Bootstrap-based icons /// </summary> Public class Bootstrapicon:basebll<bootstrapiconinfo>
such as the inheritance of the Idal layer is as follows
/// <summary> /// Bootstrap-based icons /// </summary> Public Interface Ibootstrapicon:ibasedal<bootstrapiconinfo>
Oracle-based data access layer in daloracle, we see the following inheritance relationships.
/// <summary> /// Bootstrap-based icons /// </summary> Public class Bootstrapicon:basedaloracle<bootstrapiconinfo>, Ibootstrapicon
The entity-level inheritance relationships are as follows.
/// <summary> /// Bootstrap-based icons /// </summary> Public class Bootstrapiconinfo:baseentity
These modules, due to the encapsulation of the base class, most of the logic no longer rewrite the code, about their specific content, you can refer to the previous Development Framework introduction article understand, here no longer repeat, mainly used to introduce the other module layer inheritance relationship.
3) for the Web API service layer
Web API If the business module is more, you can refer to my previous essay, "Web API project using area to classify the business" using areas to classify the management of the business, in general, we provide the interface class for each WEB API to manage the base class, As with our other modules.
/// <summary> /// all interface base classes /// </summary> [exceptionhandling] publicclass Baseapicontroller:apicontroller
And
/// <summary> ///This controller base class is specifically designed to access the data business object based on the base class/// </summary> /// <typeparam name= "B" >business Object Type</typeparam> /// <typeparam name= "T" >entity class type</typeparam> Public classBusinesscontroller<b, t>: BaseapicontrollerwhereB:class whereT:WHC. Framework.ControlUtil.BaseEntity,New()
In this way, basic additions and deletions and other conventional interfaces, we can directly invoke the business logic class within the base class to implement data processing, the specific business subclass this does not need to rewrite these interface implementations.
/// <summary> ///querying the database to see if an object with the specified ID exists/// </summary> /// <param name= "id" >the ID value of the object</param> /// <returns>The specified object is returned if it exists, otherwise null is returned</returns>[HttpGet] Public VirtualT FindByID (stringIdstringtoken) { //If the user token check does not pass, the myapiexception exception is thrown. //Check whether the user has permission or throw mydenyaccessexception exception Base. Checkauthorized (Authorizekey.viewkey, token); T Info=Basebll.findbyid (ID); returninfo; }
For the conventions of HttpGet and HttpPost, we use the former for the regular acquisition of data, if we modify the data, or if we need parameters of complex type, we use post to handle it.
The inheritance relationship for subclasses is as follows
/// <summary> /// User Information Management controller in privilege system /// </summary> Public class Usercontroller:businesscontroller<user, userinfo>
So this usercontroller has all the functions of the base class, only need to implement some specific interface processing.
For example, we can define a new Web API interface, as shown below.
/// <summary> ///get user objects by user name/// </summary> /// <param name= "UserName" >User name</param> /// <param name= "token" >Access Tokens</param> /// <returns></returns>[HttpGet] PublicUserInfo Getuserbyname (stringUserName,stringtoken) { //token Check, throw exception if not passedCheckresult Checkresult =Checktoken (token); returnBllfactory<user>. Instance.getuserbyname (UserName); }
For the Web API architecture, the entire inheritance of the controller is probably as follows.
If the area is used to classify business modules, the entire Web API project is structured as follows, with separate business areas that facilitate the maintenance of business module code, where Baseapicontroller and Businesscontroller are common web Encapsulation processing of API interfaces.
4) for the Web API wrapper layer
In order to achieve the WinForm hybrid framework and Web-mixed framework for the common use of the Web API Services Packaging layer, then we need a separate Web API wrapper layer, that is, the ***caller layer, including the direct access to the database, the Web API Service Interface access mode, Or a package layer that adds the way WCF services are accessed.
The purpose of this layer is to dynamically read the URL address of the Web API interface and to encapsulate the cumbersome details of access to the Web API interface, which makes it easy and quick for callers to access the Web API interface.
The architecture of the entire WEB API wrapper layer is based on the facade interface layer for different adaptation, such as direct access to the database mode, WEB API service access way of adaptation processing, so that when the client calls, automatically from different interfaces to implement the instantiation of the object, from different ways to obtain the required interface data.
For the user object, let's cite an example to illustrate the inheritance relationship between the caller layers.
The interface definitions in the facade layer are as follows.
Public Interface Iuserservice:ibaseservice<userinfo>
The implementation class code for the caller layer in WEBAPI is shown below.
/// <summary> /// Facade interface Implementation class based on Webapi mode /// </summary> Public class Usercaller:baseapiservice<userinfo>, Iuserservice
For the direct connection method, the code for the implementation class is as follows.
/// <summary> /// Facade Interface Implementation class for direct access to local database based on traditional WinForm method /// </summary> Public class Usercaller:baselocalservice<userinfo>, Iuserservice
So we sort them out as shown in the relationship.
For different business modules, we implement different caller layers based on the corresponding different facade layer interfaces, so that even with many project modules, we can easily maintain them individually, when WinForm client or the Web side calls caller layer, The corresponding caller layer project needs to be introduced, as well as the core layer of the business.
For example, we need to introduce the core layer and the caller layer when we use it, and the following is a partial reference relationship in the project.
5) for the Web interface layer
This web interface layer, is mainly the consumption of facade layer interface implementation, to obtain data display in the interface, our interface through the HTML + JS Ajax way to achieve from the MVC controller interface to obtain data, then we are still in the controller layer for convenience, the abstraction, In order to extract the normal method into the base class, the class code does not have to be duplicated.
This change, for our existing MVC project, the View processing code does not need any change, only need the controller to the data access processing adjustment, so that the MVC common way to obtain the interface layer of data, smooth transition to the Web-based API + direct access to the database in a hybrid approach.
The design of the MVC View Controller, which originally accessed the database directly, is essentially similar to the design process for the controller in the Web API, as shown below.
In the case of MVC's web interface layer, which accesses data in a hybrid way, we need to introduce a new controller to implement the adaptation process.
This builds up an inheritance diagram similar to the above Web MVC controller.
The difference is that any method of accessing data inside the call, from the original bllfactory<t> to callerfactorry<t> conversion, so that the simple direct access to the database, the way to switch to the hybrid access to data, Inside the web framework, it can be configured to directly access the database, or it can be configured to access the data through the Web API.
For example, the code for an inheritance relationship class is as follows.
/// <summary> /// User Information Controller class based on hybrid access method /// </summary> Public class Usercontroller:apibusinesscontroller<iuserservice, userinfo>
For the controller on the Web interface side, the background controller code that uses the hybrid access method is shown below.
/// <summary> ///get the corresponding user based on the role/// </summary> /// <param name= "Roleid" >role ID</param> /// <returns></returns> PublicActionResult Getusersbyrole (stringRoleid) {ActionResult result= Content (""); if(!string. IsNullOrEmpty (Roleid) &&Validateutil.isvalidint (Roleid)) {List<UserInfo> rolelist = callerfactory<iuserservice>. Instance.getusersbyrole (Convert.ToInt32 (Roleid)); Result=tojsoncontent (rolelist); } returnresult; }
That is, from the traditional bllfactory<user> conversion to CALLERFACTORY<IUSERSERVICE>, the overall interface changes very small, it is easy to transition to a mixed mode of access.
The above is my introduction from the entire Web project based on hybrid access, throughout the entire data transmission route and call route, of course, there are many details to be detailed, and need some more ingenious integration package processing, the whole purpose is to hope that the use of hybrid access ideas, The integration of multiple data access methods, and the maximum simplification of the coding of subclasses, and the creation of various layers of code through the use of code generation tools, we focus on how to implement different business interfaces, so that we can quickly develop complex applications, and can reasonably maintain the code of each project.
Summarize the whole development in a word: simple, unified, efficient.
Use Web APIs and direct connect in MVC-based Web projects two ways hybrid access