I am asking more of a fundamental questions which might sound rather obvious. What is the logic to decide that we should create multiple class library projects in a solution?
For e.g: I am planning to create a application for a client, which is like a ERP and would have multiple modules like Inventory, Purchase, Sales, Accounting, Manufacturing, CRM, etc. Now, there are two ways through which i can design the solution.
First is create a Solution in .NET and add class library project for business logic and website project for each of the module for UI.
Or
Secondly, create multiple solutions for each of the module and each solution would have two project, one class libary for Business logic and one website project for pages.
Now, i am not sure which one is right and what are the deciding factors on which we decide whether to go with option 1 or 2. DO let me know if there are some better option as well.
We are splitting the project into many smaller projects, because
Abstraction
Maintainable
Updatable
Error identification
Individual project can use in another solution
SOA kind of project can execute separate environment, so possible to reduce workload, for example if a project spitted into
UI
BLL
DAL
All three, layer are executing individual system; when UI receive any request it send to the another system; logic verified and send to another DAL system; here workload of UI, BAL and DAL would be reduced; also DAL keep on changing their version, not necessary
to outage on production (some time expect); can update easily. And most important is
abstraction, necessary only we need to show; whoever working for BLL they no need to know how DAL build and connectivity.
I am planning to create a application for a client, which is like a ERP and would have multiple modules like Inventory, Purchase, Sales, Accounting, Manufacturing, CRM, etc.
It soundls like you would like to use a traditional 3-layer UI-BLL-DAL architecture to design your system which is appropriate based on your description. It really is fine to have a single .NET solution that contains (3) different projects as displayed
below:
Solution -> MyWebApp
UI -> MyCompany.MyWebApp.UI
BLL -> MyCompany.MyWebApp.BLL
DAL -> MyCompany.MyWebApp.DAL
All of the different 'modules' you highlighted are really 'classes'. You should at a minimum have 1 class for each if the topics you listd (maybe more as you begine to lay out the design and how everything interacts).
The only reason to refactor out any individual class into its own project or even solution is if you needed it across many applications and wanted to share it is a WCF service or some other reusable component (.dll). Otherwise having all of the logical layers
(projects) within one solution should work just fine.
Project.Web (UI)
Project.Controls (reusable .ascx controls, like GridView data)
Project.BusinessLogicLayer (code between UI/Controls to DataAccessLayer)
Project.BusinessObjectLayer (class object directly built from database tables)
Project.DataAccessLayer (code to access db)
TusharDave
0 Points
2 Posts
How to decide that multiple class library projects are required.
Feb 16, 2012 07:21 AM|LINK
Hello Friends,
I am asking more of a fundamental questions which might sound rather obvious. What is the logic to decide that we should create multiple class library projects in a solution?
For e.g: I am planning to create a application for a client, which is like a ERP and would have multiple modules like Inventory, Purchase, Sales, Accounting, Manufacturing, CRM, etc. Now, there are two ways through which i can design the solution.
First is create a Solution in .NET and add class library project for business logic and website project for each of the module for UI.
Or
Secondly, create multiple solutions for each of the module and each solution would have two project, one class libary for Business logic and one website project for pages.
Now, i am not sure which one is right and what are the deciding factors on which we decide whether to go with option 1 or 2. DO let me know if there are some better option as well.
Mastan Oli
Contributor
5088 Points
998 Posts
Re: How to decide that multiple class library projects are required.
Feb 16, 2012 09:35 AM|LINK
Good question…
We are splitting the project into many smaller projects, because
SOA kind of project can execute separate environment, so possible to reduce workload, for example if a project spitted into
All three, layer are executing individual system; when UI receive any request it send to the another system; logic verified and send to another DAL system; here workload of UI, BAL and DAL would be reduced; also DAL keep on changing their version, not necessary to outage on production (some time expect); can update easily. And most important is abstraction, necessary only we need to show; whoever working for BLL they no need to know how DAL build and connectivity.
Hope you understand!!!
Please have a look
playingOOPS | மெய்ப்பொருள் காண்பதறிவு
Mark as Answer If you find helpful
atconway
All-Star
16846 Points
2756 Posts
Re: How to decide that multiple class library projects are required.
Feb 20, 2012 02:11 AM|LINK
It soundls like you would like to use a traditional 3-layer UI-BLL-DAL architecture to design your system which is appropriate based on your description. It really is fine to have a single .NET solution that contains (3) different projects as displayed below:
Solution -> MyWebApp
UI -> MyCompany.MyWebApp.UI
BLL -> MyCompany.MyWebApp.BLL
DAL -> MyCompany.MyWebApp.DAL
All of the different 'modules' you highlighted are really 'classes'. You should at a minimum have 1 class for each if the topics you listd (maybe more as you begine to lay out the design and how everything interacts).
The only reason to refactor out any individual class into its own project or even solution is if you needed it across many applications and wanted to share it is a WCF service or some other reusable component (.dll). Otherwise having all of the logical layers (projects) within one solution should work just fine.
RagMan85
Member
43 Points
18 Posts
Re: How to decide that multiple class library projects are required.
Mar 05, 2012 02:11 PM|LINK
Mastan Oli hit the nail on the head.
Here's how we do it:
Project.Web (UI)
Project.Controls (reusable .ascx controls, like GridView data)
Project.BusinessLogicLayer (code between UI/Controls to DataAccessLayer)
Project.BusinessObjectLayer (class object directly built from database tables)
Project.DataAccessLayer (code to access db)
We modeled this from Spaanjaar's series: http://imar.spaanjaars.com/476/n-layered-web-applications-with-aspnet-35-part-1-general-introduction