4

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

I make a specific .NET framework (web application). This web application acts like a platform or framework to many other web applications through the following methodology :

We create our dependent web applications (classes for the project business, rdlc reports) in a separate solutions then build them.

After that we add references to the resulted dll in the framework.

And create set of user controls (one for each dependent web application) and put them in a folder in the framework it self.

It works fine but any modification to a specific user control or any modification to any one of the dependent web applications. We have to add the references again and publish the whole framework !!

What I want to do is make those different web applications and the framework loosely coupled. So I could publish the framework one and only one and any modifications to the user controls or the different web applications just publish the updated part rather than the whole framework .

How to refactor my code so I can do this?

The most important thing is :

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

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Anyname Donotcare
  • 11,113
  • 66
  • 219
  • 392

3 Answers3

4

If loose coupling is what you are after, develop your "framework(web application)" to function as a WCF web service. Your client applications will pass requests to your web services and receive standard responses in the form of predefined objects.

If you take this route, I recommend that you implement an additional step: Do not use the objects passed to your client applications directly in your client code. Instead, create versions of these web service objects local to each client application and upon receiving your web service response objects, map them to their local counterparts. I tend to implement this with a facade project in my client solution. The facade handles all calls to my various web services, and does the mapping between client and service objects automatically with each call. It is very convenient.

The reason for this is that the day that you decide to modify the objects that your web service serves, you only have to change the mapping 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 quite a large subject. If you are interested, a book that I recommend is Programming WCF Services. It offers a pretty good introduction to WCF development for those who come from a .NET background.

Levi Botelho
  • 24,626
  • 5
  • 61
  • 96
2

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

  1. As an alternative to WCF (with its crazy configuration needs), I would recommend ServiceStack. Like WCF it lets you receive requests and return responses in the form of predefined objects, but with NO code generation and minimal configuration. It supports all kinds of response formats, such as JSON, XML, JSV and CSV. This makes it much easier to consume from f.ex. JavaScript and even mobile apps. It even has binaries for MonoTouch and Mono for Android! It is also highly testable and blazing fast!

  2. A great tool for the mapping part of your code is AutoMapper, it lets you set up all your mappings in a single place and map from one object type to another by calling a simple method.

Check them out! :)

khellang
  • 17,550
  • 6
  • 64
  • 84
1

Decades of experience says: avoid the framework and you won't have a problem to solve.

Frameworks evolve like cancer. The road to hell is paved with good intentions, and a good portion of those good intentions are embodied in a colossal tumour of a framework all in the name of potential re-use that never really happens.

Get some experience and knowledge when it comes to OO and design, and you'll find endless solutions to your technical problem, such as facades, and mementos, and what have you, but they are not solutions to your real problem.

Another thing, if you are using MS technology, don't bother with anything beyond what .NET offers. Stick with what the MS gods offer because as soon as you digress and become committed to some inhouse framework, your days are numbered.

Sentinel
  • 3,582
  • 1
  • 30
  • 44