DotNET Enterprise Architecture Application practices-interface-based development introduction and application scenarios and Cases

Interface-based development

The essence of interface-based programming is to separate the relationship between object implementation and users, that is, to change the dependency changes of the following object structure:

 

 

 

The advantage of this is that the customer object depends on the service interface. in the development process, we only focus on the definition of the service interface, but not on the specific implementation of the service object, only at runtime can a customer object achieve dynamic recommendations and dependencies between the customer object through decoupling and binding auxiliary tools (classes) and specific services.

The advantage of doing so is that technically, if we place the service interfaces and Service implementations in different components, we modify the service implementation components, we do not need to recompile customer components. The benefit of software engineering is that service interfaces and service components, that is, interface definitions and implementations, can be separated and can be handed over to different people, at the same time, we can use this structure to achieve dynamic configuration at runtime to replace different service components.

One application scenario and case

For example, if we want to develop a HIS system, we need to integrate medical insurance. However, if we use different medical insurance systems in different regions, our HIS system must be in line with the unsuitable medical insurance system, but we cannot change the relevant logic in HIS because of the application of different medical services. What should we do?

The answer is to use the interface-driven idea. We define an HIS medical insurance interface component (HIS. medicare. interface). In HIS system, the method or service that calls this Interface in the place where the medical insurance service is used, while in the process of implementing HIS in different cities, develop healthcare and insurance implementation components for various cities, such as HIS. medicare. lanzhou, HIS. medicare. baoTou, we can also get an empty implement HIS. medicare. default, that is, if medical insurance is not used, the entire structure is as follows:

 

 

HIS. medicare. the Interface consumer calls HIS for all insurance services. medicare. the business definition component in the Interface package does not care about the implementation that is used when the system is running, or it is not implemented or there is only one default implementation HIS. mecicare. default: Maybe the actual implementation of the runtime environment has not yet been developed, and can be developed only in the project. How do consumers establish a connection with the implementation of interfaces?

Post-implementation binding

There are many ways to build relationships between consumers and specific implementations. The most common method is to use the image factory model or the IOC container for decoupling. How can we say this, the following is an example.

For example, we define an Interface IMedicareProvider in his. Medicare. Interface.

 

1 public interface IMedicareProvider
2 {
3 IMedicareDrugSelect CreateMedicareDrugSelect ();
4
5 IMedicareItemInfoSelect CreateMedicareItemInfoSelect ();
6
7 IMedicareServiceSelect CreateMedicareServiceSelect ();
8}

 

 

In HIS. medicare. lanzhou, HIS. medicare. baoTou and HIS. medicare. this class is implemented in Default, so we can just. medicare. add the following code to the Interface component:

  1     public static class MedicareProviderHelper
 2     {
 3         static readonly string ConfigKey = "HIS.MedicareProvider";
 4         public static IMedicareProvider MedicareProvider
 5         {
 6             get
 7             {
 8                 return ContextHelper.GetContext().Container.GetComponentInstance(ConfigKey) as IMedicareProvider;
 9             }
10         }
11     }
 

Add the following content to the IOC configuration information of the system configuration file:

1 <object name = "HIS. MedicareProvider" assembly = "HIS. Medicare. Default" type = "HIS. Medicare. Default. MedicareProvider" LifestyleType = "Thread"/>

 

I have used the IOC component in the AgileEAS. NET platform for processing above. For more information about IOC, see the article on Object Control reversal of AgileEAS. NET platform. After this processing, the IMedicareProvider object will be consumed directly in the way of medicine areproviderhelper. IMedicareProvider wherever the IMedicareProvider interface is used.

Conclusion

Facts show that interface-based development can effectively isolate the dependencies between service objects and consumer objects in some application scenarios. It is a very effective method in the software development process, if the application is reasonable, it will play a half-game effect. However, interface-based development is not the only silver bullet that does not solve the problem, just like our traditional files, the Design of architecture or model is based on the principle of application first, that is, what kind of business is what kind of architecture technology, rather than simply forcing and copying. Reasonable.

I am not adding some ads. Thank you!

Link

Step by step teach you how to use the AgileEAS. NET base class library for application development-series directory

AgileEAS. NET platform development guide-series Directories

Introduction to AgileEAS. NET application development platform-Index

AgileEAS. NET platform application development tutorial-case plan

Official website of AgileEAS. NET

Agile Software Engineering Lab

QQ group: 116773358 (AgileEAS. NET platform), 9105332 (System Architecture Communication Group)