Last post Mar 05, 2012 02:11 PM by RagMan85
Feb 16, 2012 07:21 AM|TusharDave|LINK
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.
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.
Feb 16, 2012 09:35 AM|Mastan Oli|LINK
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
Feb 20, 2012 02:11 AM|atconway|LINK
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
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.
Mar 05, 2012 02:11 PM|RagMan85|LINK
Mastan Oli hit the nail on the head.
Here's how we do it:
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: