Integration of two different applications in ASP.NET MVC

2

Hello, I need to integrate two distinct applications: one is a client business administration application and the other a financial management application.

They are two separate applications, so what I need is that when you register a customer in the administration application, that customer is integrated into the real-time financial application.

What I already thought:

As the applications were developed in Asp.Net and following the concepts of DDD and I get the DLLs of services and refer them in the other application, I also refer to the Model DLL and so I can create a client object from the financial application, access the method and add it using its business rule logic.

I just do not know if this is the best way. I've thought of integrating in this way using DLLs, I've already thought about doing the Web API in the controller I would call the integration API by passing a JSON.

I also thought of doing an integrator program that had time and did this integration by doing selects and inserts from time to time.

I would like your opinion. Should I use only the DDD service layer? Should I use Web API? Or some other approach?

What is the advantage and disadvantage of each?

    
asked by anonymous 18.03.2016 / 15:40

2 answers

1
  

I just do not know if this is the best way. I've thought of integrating in this way using DLLs, I've already thought about doing the Web API in the controller I would call the integration API by passing a JSON.

There are several advantages to doing this internally. Because your applications already have a common middle layer between them, just reference the DLL and use it.

The API approach is interesting if the integration is by a service or application that you do not have control over the code. Other than that, the most cohesive alternative is always the best.

  

I also thought of doing an integrator program that had time and did this integration by doing selects and inserts from time to time.

This is not a good alternative because you do not have data availability in real time. You have to wait for your integrator service to run to have the information available.

Another design pattern

There is a third design pattern that is interesting to mention, and that would be best for your case, which is to make one application read the other's data context, but this would only be valid if you do this from the Entity Framework.

As in your response you have already said that you have a service layer that does this for you, it means that there is no such mapping concern, since the entire application is with the integrated data domain.

    
18.03.2016 / 16:56
0

Hello.

Since the applications are ready and running, I think the best thing to do would be to use the Web API, creating a method in each application that would be called to insert a user. When a user was created in one of the applications, this application would call the other application's method with the data of that new client, and thus the two applications would be integrated. This seems to be the simplest and fastest solution, but you would need to do some manual work to synchronize existing clients.

Another option would be to use an integrated database. In this way, the table that stores the customer information could be shared between the two applications. But that would require a restructuring in the applications' current architecture.

If you want the user to have a single login to access both applications, you could use a common database to perform user authentication. This way, a user would only have to authenticate once and could access several applications. Each application would continue to function independently, and the user session would ensure that it is authenticated. This solution would require an even greater effort to adapt the current architecture, but it could be very positive for the user experience to be able to access all the applications by just authenticating.

The final decision is yours, but I hope I have helped.

    
18.03.2016 / 17:00