Sharing my repository (repository pattern) with other projects(.NET)?

Question

Hi there,

i am trying to tidy up my code, i have a number of projects that have References to my Service Layer i.e the DLL. What this means is that when i distribute a new service layer i have to upload a number of service layers which are generally the same..

Of course using the ADD Reference is very fast as its one assembly talking to another...

I wanted to know the pros and cons of an alternative method..

I could use a web service/wcf to wrap my service layer but isn't this defeating the object..

And what about speed, now my desktop applications need to call to web service/wcf instead of accessing the assembly reference??

My service layer talks to my data layer of course and my clients nevere talk to the data layer directly..

Its the issue of the service layer which is where my business logic is which is shared amongst a number of apps..

Desktop app, 2 x website, 2 x wcf projects(used as web services)

Any advice on how i can achieve the fastest possibly scenerio without repeating my code which is effect what i am doing now i.e.

each app (desktop, website, wcf) have copies on the same DLL and have references (add reference in vs 2008) ..

Ideas?

Answer 1

If you deploy apps mostly on a single host, then chose publishing your middle-layer in GAC, supplying it with appropriate version policy.

If you deploy apps in a distributed environment, then use .NET remoting/WS/WCF. I think that remoting will be the fastest choice in your scenario.

Answer 2

I think you would benefit best by using WCF (which wraps up .net remoting, msmq, etc.). Then you wouldn't have to copy a dll with each program... they can just point to a WCF service. This type of service oriented architecture is great for what you are describing.

From my experience with WCF so far, I have not noticed any performance hits, especially on an internal network.

Here's a good overview on WCF: http://msdn.microsoft.com/en-us/library/aa480210.aspx

Hope this helps!