locked
Architecturing layers into different solutions? RRS feed

  • Question

  • Dear friends,

    I decided to establish my new architecture based on the guidance which is provided by some VS2010 Rangers  in Visual Studio 2010 Architecture Tooling Guidance(http://vsarchitectureguide.codeplex.com)

    One of their advices mentions breaking the projects layers into different solutions . then we will have UI solution, Biz Solution and so on... I think it is also good in separation of concerns theory but the problem arises when we want to do it in a team. As this guidance mentioned (at the bottom of page 24) we should write some "Post-Build Events" to copy Dlls to a shared location. then the project in other solutions can reference them easily. But it makes problem when we work under source control when the shared place is not located under the source control.

    Assume this scenario :

    we have 3 different solutions : UI ,Biz and Entities . and the both first one references Entities solution outputs.

    user1 works on UI and Entities .

    user2 works on Biz and Entities .

    then both of them have a shared place for their own (user1Share ,user2Share )

    the first problem is : they should configure their project manually to output their entities build to userXShare folder.

    the second problem is under source control. if user2 changes something in entities, user1 should 1st get it from then source control and then BUILD it to take effect. This second build is really a drawback. The user1 's entities solution may not be opened at that time and we obligate him to reopen it,build it and then return to his UI project...

    can anyone help on this? Am I true on this discussion?

    Thanks in advance,

     

     


    Mahmoud Moravej
    Saturday, February 5, 2011 8:06 AM

All replies

  • Separate solutions forces you to ensure separation of concerns in that particular aspect.

    Other than that I'm not convinced there's a benefit.

    There's clearly a cost in increased complexity and mucking about with copying DLLs.

    The thing to decide is whether the cost outweighs the benefit for your team.

    Personally, I would recommend structuring with the layers in one solution, separate folders.    Insist on code walk throughs to ensure people are separating concerns properly AND share knowledge.

    Added benefit, less cost.

    Tuesday, February 8, 2011 10:45 AM
  • I would have to agree with Andy1559 here.

    For me a solution is a logical component that should be able to function on it's own. If a solution is dependent on a external library it should refrenced using a sharedLib folder used exlusivly by that solution.

    If you need to share a solution that is used by two solutions the best thing is to try to see if you have organised your shared solution properly iaw can it be fit into one project. For something called entities, you should be able to reference it as an existing project in the two dependant solutions.

    I you would still like to have the three solution option I would suggest to arrange your buildserver in such a way that it set all the dependancies for you.

    UI -Sharedlib

    BIZ -> SharedLib

    Entities -> check in -> Buildserver outputs binaries in both sharedLibs of UI and BIZ.

    Now if entities screw up any stuf in UI or BIZ the buildserver will notify the UI or BIZ teammembers.

     

     

     

    Tuesday, February 8, 2011 12:52 PM
  • I'm not going to comment on the pro's/con's of how to separate out the solutions - tbh I haven't found an ideal way yet. However, to your specific problem, why not just have a well known shared folder on a server to place your shared resources  (dlls, pdbs, etc) into?

    I do work on a project that is configured more like yours and one of the team has created a separate app whose sole role is to copy dlls around. I would would certainly think before leaping down than route.  


    http://pdkm.spaces.live.com/
    Wednesday, February 9, 2011 11:15 AM
  • Dear Andy,

    I think sepration of concerns is really beneficial specially in team working and maintenance even for medium-size teams. (as scottgu says here(item:g http://weblogs.asp.net/scottgu/archive/2010/01/24/about-technical-debates-both-in-general-and-regarding-asp-net-web-forms-and-asp-net-mvc-in-particular.aspx )

    also some ALM Rangers specified it here : http://vsarchitectureguide.codeplex.com/ (page 22 of guidance)

    All the codes I need to reach this sepration (in single machine/no TFS) are adding some codes in Post-Build Events to copy the dlls to a shared folder. The problem is just when we are in TFS, where I need an similar way(i.e. Post-Checkin event and runnig some codes in TFS or something like this)...but its a little more complex!


    Mahmoud Moravej
    Sunday, February 13, 2011 9:03 AM
  • Hans,

    I prefer to use a single solution rather than build server!


    Mahmoud Moravej
    Sunday, February 13, 2011 9:11 AM
  • pkr2000,

    shared folder makes lots of problem in team working. moreover shared folder is the answer when we don't have TFS but under TFS it fails completelly.


    Mahmoud Moravej
    Sunday, February 13, 2011 9:13 AM
  • Why does it fail?
    http://pdkm.spaces.live.com/
    Sunday, February 13, 2011 4:44 PM
  • Hi Mahmoud,

     

    If your keen on guidance here an article that gave me some good insight as to seperation of concerns as to the partitioning actually needed:

    http://codebetter.com/jeremymiller/2008/09/30/separate-assemblies-loose-coupling/

    http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-through-net-assemblies/

    Basically if tells you when you put stuff in different assemblies, see if your situation applies. I cannot think of working in a team without source control and a buildserver. But I know lot of people do without a buildserver, but its so damn handy to have that continuous intergration going on ;-)

    Cheers

    Hans

     

    Monday, February 14, 2011 8:25 AM