How to make structure and dependent applications loosely coupled?

I have a specific case, and I want to know the best practice way to handle it.

I am creating a specific .NET platform (web application). This web application acts as a platform or infrastructure for many other web applications using the following methodology:

We create our dependent web applications (classes for business projects, rdlc reports) in separate solutions, then we create them.

After that we add links to the given dll within the framework.

And create a set of user controls (one for each dependent web application) and put them in a folder in your structure.

It works fine, but any changes for a specific user control or any changes for any of the dependent web applications. We must add links again and publish the whole structure!

What I want to do is that these various web applications and the framework are loosely coupled. Therefore, I could publish the framework one and only one and any changes in user controls or various web applications just publish the updated part, and not the whole structure.

How to reorganize my code so that I can do this?

The most important thing:

Never publish the whole structure if the change in any dependent application, just publish the updated part, belongs to this application.

+4
source share
3 answers

If you need free communication, create your own “framework (web application)” to work as a WCF web service. Your client applications will forward requests to your web services and receive standard responses in the form of predefined objects.

If you use this route, I recommend that you take an additional step: do not use objects transferred to client applications directly into your client’s code. Instead, create versions of these web service objects locally for each client application and, after receiving the web service response objects, map them to your local copies. I try to implement this with the help of a facade design in my solution for clients. The facade handles all calls for my various web services and automatically maps each call between clients and service objects. It is very comfortable.

The reason is that on the day you decide to change the objects served by your web service, you only need to change the matching algorithms in your client applications ... the internal code of each client solution remains unchanged. Do not underestimate how much work this can save you!

Developing WCF web services is a pretty big question. If you're interested, I recommend the book Programming WCF Services . It offers a pretty good idea of ​​developing WCF for those coming from the .NET background.

+4
source

I totally agree with levib, but I also have some tips:

  • As an alternative to WCF (with its crazy configuration needs), I would recommend ServiceStack . Like WCF, it allows you to receive requests and return responses in the form of predefined objects, but without code generation and minimal configuration. It supports all kinds of response formats, such as JSON, XML, JSV and CSV. This greatly facilitates consumption with f.ex. JavaScript and even mobile apps. It even has binaries for MonoTouch and Mono for Android! It is also very easy to test and flashes quickly!

  • AutoMapper is a great tool for the display part of your code, it allows you to configure all your mappings in one place and map from one type of object to another, calling a simple method.

Check them out! :)

+2
source

Decades of experience say: Avoid the framework and you will not have a problem to solve.

Frames evolve like cancer. The road to hell is paved with good intentions, and a good part of these good intentions is embodied in a colossal tumor of the frame in the name of potential reuse that never happens.

Gain some experience and knowledge when it comes to OO and design, and you will find endless solutions to your technical problem, such as facades and souvenirs, and what you have, but they are not the solution to your real problem.

Another thing, if you use MS technology, do not worry about anything other than what .NET offers. Stick to what the MS gods offer, because as soon as you get distracted and move on to some kind of internal structure, your days are numbered.

+1
source

Source: https://habr.com/ru/post/1447679/


All Articles