Home > Development > SOA Services and the Many Visual Studio Solution File Problem

SOA Services and the Many Visual Studio Solution File Problem

We’re working on a new project at work which is going to be implemented with a number of components with varying levels of dependencies on one another.  Since we knew that this project was to be quite large we thought it would be rather nice if we split the entire System into many Visual Studio solutions.   This would encourage components to be accessed via established contracts instead of potentially back-door methods.  It creates a rather friendly “black-box” perception of said components when you can only see the referenced .DLL instead of spying source code.

Sadly we ran into a problem which I suspect others have come across at one time or another – it can lead to circular dependencies when one project depends on contracts in another whilst at the same time one component may require say a Windows Communication Foundation (WCF) client proxy.  This is quite significant when many of the components are of the WCF variety.

One solution of course particularly when dealing with Service Orientated Architecture (SOA) is to adopt a Schema First practice whereby you define all your types, messages in XSD format rather than leaping straight into say c#.   Sadly, Schema First can be a bit like designing all your .net classes in a modelling tool where the code is generated – it’s nice but not particularly productive.  Plus, unless you have the rather good Stylus Studio and WSCF.blue tools, who wants to hand-crank XSD and WSDL just to add an extra argument to a method?  Not many agile programmers I don’t think.

Another possibility is to take all your .net domain classes and contracts for all the WCF services and place them in a separate solution.  Though this is arguably faster than code generation from modelling tools or schema first, it is rather annoying when you wish to refactor your code.   Renaming a method in the contracts solution won’t automatically rename the classes in the implementation solutions.

Ultimately having many Visual Studio environments open just for contracts and the services just plain sux, particularly when you need to compile things in a particular order.

So I’ll be boggled if I know what to do for the short to medium term.  I suppose we’ll just continue what seems to be the common practice – have a monolithic Visual Studio solution that at some point in the future we can split up once code changes become idle.

Which opens up another can of worms – splitting up the code introduces a reasonable level of risk particularly when we can assume that its already been QA’d.

I’d love to hear if anyone has some great ways to solve this dilemma.

Advertisements
Categories: Development Tags: , ,
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: