locked
Creating multiple projects within a solution (When?) RRS feed

  • Question

  • User192569596 posted

    I am about to embark on what I am sure will be another short lived project but before I do I have the following design question.

    When should a new project be added to a solution?

    Say for instance I was creating a wiki (pedia) type site and have the following core components.

    • UI
    • Memberships
    • Search
    • Mobile

    My assumption would be that all would be seperate projects with additional projects for shared classes e.g. DAL and BLL.

    Normally I would create all within the same project but have been in a couple of debates (read arguements!!) recently where I have been told I should seperate these into their own projects.

    Saturday, July 21, 2012 1:17 PM

Answers

  • User1035491367 posted

    That makes sense but architectually what benefits are provided by this approach? I can see the benefit if I was creating say a warehouse management system where there was a Web/Client UI and a console app (For HHT's) i.e. differnt project types but when the entire project will be comprised of pages and classes (over simplified example) why not seperate into their own folders as opposed to seperate projects?

    There are two reasons 

    Firstly : It will be easy for managment , it is to make aggregation for all related project to One Solution

    Secondly : to Isolate the Logic in BusinessLogic Layer and DB Functions to Data Access layer to use them Only with all the projects in the solution and when all layers and projects related to one solution , it will be easy to move to any machine and work with each other without  determine each dll path , and update any code at any layer easy and it will reflect automatically to whole the solution

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 23, 2012 7:43 AM
  • User-760709272 posted

    Separating projects also aids unit testing as your business and data layers are not dependant on web constructs like an http context etc.  It also allows you to re-use the same code for different front ends, but it is fairly rare for that to happen in real life.  Similarly it allows you to swap out layers.  So if you move from Access to SQL, or from SQL to using XML files, you only need to change your data project to use the new storage method.  Again that's a rarity in real life.  The main reason you'll want to do it is to keep things clean and separate, and ensure each component's roles and functions are clearly defined.  It makes things easier to work with.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 23, 2012 7:58 AM
  • User-1184423958 posted

    There are many reasons to seperate business logic/ data access layers into its own tier. Few are here,

    • It keeps all of your business logic/data access layer localized, and in one place. Future changes will be much easier as a result.
    • It allows you to more easily unit test your business logic. It's very difficult to write automated unit tests against your business logic if this code is tightly coupled to your web page, or windows form.
    • It keeps your UI much slimmer.

    Read basic OOP Single responsibility principle

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, July 25, 2012 1:51 AM
  • User-1362334014 posted

    Generally, one create multipe projects, depending on 

    • How large the module is. (Its is separated for simplicity).
    • Does the module widely differ from each other.
    • Different level of complexity permissions, usage or purpose of each module.

    Now, if you are able to achieve your moto having all within a single project and don't have any issue like data reusing or any added complexity, you could continue with a single project. This will reduce your project maintenance time. Though, these are general assumptions, you could select the best way as per your requirements.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, July 25, 2012 9:31 AM

All replies

  • User197322208 posted

    My assumption would be that all would be seperate projects with additional projects for shared classes e.g. DAL and BLL.

    Yes.

    Normally I would create all within the same project but have been in a couple of debates (read arguements!!) recently where I have been told I should seperate these into their own projects.

    Yes. Main reason: this way you will not use data from a layer to another, but just methods.

    Saturday, July 21, 2012 4:09 PM
  • User192569596 posted

    Yes. Main reason: this way you will not use data from a layer to another, but just methods.

    That makes sense but architectually what benefits are provided by this approach? I can see the benefit if I was creating say a warehouse management system where there was a Web/Client UI and a console app (For HHT's) i.e. differnt project types but when the entire project will be comprised of pages and classes (over simplified example) why not seperate into their own folders as opposed to seperate projects?

    Sunday, July 22, 2012 3:43 AM
  • User1035491367 posted

    That makes sense but architectually what benefits are provided by this approach? I can see the benefit if I was creating say a warehouse management system where there was a Web/Client UI and a console app (For HHT's) i.e. differnt project types but when the entire project will be comprised of pages and classes (over simplified example) why not seperate into their own folders as opposed to seperate projects?

    There are two reasons 

    Firstly : It will be easy for managment , it is to make aggregation for all related project to One Solution

    Secondly : to Isolate the Logic in BusinessLogic Layer and DB Functions to Data Access layer to use them Only with all the projects in the solution and when all layers and projects related to one solution , it will be easy to move to any machine and work with each other without  determine each dll path , and update any code at any layer easy and it will reflect automatically to whole the solution

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 23, 2012 7:43 AM
  • User-760709272 posted

    Separating projects also aids unit testing as your business and data layers are not dependant on web constructs like an http context etc.  It also allows you to re-use the same code for different front ends, but it is fairly rare for that to happen in real life.  Similarly it allows you to swap out layers.  So if you move from Access to SQL, or from SQL to using XML files, you only need to change your data project to use the new storage method.  Again that's a rarity in real life.  The main reason you'll want to do it is to keep things clean and separate, and ensure each component's roles and functions are clearly defined.  It makes things easier to work with.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 23, 2012 7:58 AM
  • User1182241144 posted

    By creating different projects. its helps for reusebility. Like you have created once utility class for one project and you can use that class for another project also by making some little changes.

     

    Monday, July 23, 2012 8:39 AM
  • User192569596 posted

    My problem (only in my head!) is that as highlighted by AidyF, code is rarely reused (With notable exceptions such as regex or user auth) and very seldom used out of scope of the original solution.

    Assume for instance I have the following

    • Solution A
      • BLL 
      • DAL 
      • UI_Web 
        • Auth/membership
        • Forum
        • Blog
        • Photo Album
        • Reports
      • UI_Mobile 

    What difference does it make if each entry under solution is a project or a folder? Testing is against BLL, data storage changes can be managed within DAL, Gui's can be seperated into their own folders etc.

    I think the most compelling reason so far is the ability to host each project on a different server which would be useful in my WMS example where one project may contol wave/route planning and would benefit from dedicated hardware.

    I did find one other reason whilst researching this that was interesting regarding access levels to source code. You may wish to allow your consultant access to your search project to make it faster whilst not giving them access to your security or UI code. (Pretty sure this can be done in TFS and similar tools though.

    Thanks for all your input.

    Monday, July 23, 2012 12:57 PM
  • User-1184423958 posted

    There are many reasons to seperate business logic/ data access layers into its own tier. Few are here,

    • It keeps all of your business logic/data access layer localized, and in one place. Future changes will be much easier as a result.
    • It allows you to more easily unit test your business logic. It's very difficult to write automated unit tests against your business logic if this code is tightly coupled to your web page, or windows form.
    • It keeps your UI much slimmer.

    Read basic OOP Single responsibility principle

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, July 25, 2012 1:51 AM
  • User-578610739 posted

    Dear Mike,

    This is your choise to build solution. Ideally make section or break the problemetic things into smaller size. It will help to rectify as well as judge the problem easily , also understanding to anybody is also easy.

    You say is related to architecture. below link say 3 tier architecture which you say.

    http://www.slideshare.net/guestd0cc01/3-tier-architecture

    Also make dll of your big module is also secure for third party. and also benefit for product base application where you can give customize module given as per your client requirement.

    Wednesday, July 25, 2012 5:44 AM
  • User-1362334014 posted

    Generally, one create multipe projects, depending on 

    • How large the module is. (Its is separated for simplicity).
    • Does the module widely differ from each other.
    • Different level of complexity permissions, usage or purpose of each module.

    Now, if you are able to achieve your moto having all within a single project and don't have any issue like data reusing or any added complexity, you could continue with a single project. This will reduce your project maintenance time. Though, these are general assumptions, you could select the best way as per your requirements.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, July 25, 2012 9:31 AM
  • User192569596 posted

    I currently mainly do small self encapsulated projects but have recently been involved with a very large complex solution and whilst I can see a couple of advantages to breaking code into logical projects I am still not entirely convinced when it is just essentially a BLL and UI split. 

    The problem with this question now is how do I select an answer as this really is subjective it would appear!

    Friday, July 27, 2012 3:13 PM