locked
Modular architecture in .Net RRS feed

  • Question

  • User-1465674731 posted

    This is a question about modularzation,

    I have 3-tier architecture in my project (Presentation, BAL, DAL), i have so many objects in my applications like Employee object, Leave, Appraisal object...etc

    If i will create BAL class for each objects and DAL class for all these objects then in my DAL.dll i will have all the objects in one dll. Now the problem is the project is developed and we come to the maintenance mode now, i want to make some enhancement in Leave object and take it to production and also parellaly i want to start some major enhancements in Employee object related code and take it to production after the leave module enhancement. While developer doing Leave module enhacement they change some code and parallely Employee module team change some code in Employee related object as well. Now if i want to take only Leave module in production then i can not separate DAL and BAL because i get only one dll for DAL and BAL so i will be getting code changed in Employee DAL and BAL, so how can i take only Leave module in production.

    In php frameworks we can plugin/plogout any module anytime that is very fantastic about it. Do we have something similar to that in .Net.

    Wednesday, June 15, 2011 1:37 AM

Answers

  • User1399096257 posted

    Hi Nizam,

    As per your requirement best possible architecture is Service Oriented or Service Based Architecture (SOA). Within SOA plug in/out & modular feature is implemented by using concept of Enterprise Service Bus (ESB). Using ESB we can ON / OFF any service. We generally use this for large applications and also it is little complex &  costly. 

    Since you already have developed your application in 3-tier arch. You need do some changes using Visual Studio:

    1. Separate Presentation layer, BAL &  DAL in different projects. Put Business Entity (entity classes) in a separate project and provide its ref. to PL, BAL & DAL. You need to provide BAL ref. to PL, DAL ref. to BAL. Check project/solution properties to generate different DLLs for different project. Then on publish you will have separate DLL for each project. Now you may require to do some minor change in code in calling function or class references.  

    -- After doing this you can do what you explained in your question. Now you can maintain different versions of your DLLs. So in order to maintain versions you would need to generate strong name & register dlls.  So during deployment you can refer different versions of DLLs by defining the version number in the config file.

    -- It will solve your current problem.

    In order to make your code more maintainable in future expose your BAL to PL using an Interface layer. You can call this as service layer. You will need to create a service layer between PL & BAL. this service layer will be created by interfaces and these interfaces will expose only those functions which is ready to use. In the image below just consider Service layer as a collection of interfaces which is implemented by BAL and used by PL.

    Consider service layer as interface

    If you required any sample code I can provide you. 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, June 15, 2011 11:45 AM

All replies

  • User197322208 posted

    In php frameworks we can plugin/plogout any module anytime that is very fantastic about it. Do we have something similar to that in .Net.

    Only if you do it. See

    http://www.codeproject.com/KB/cs/c__plugin_architecture.aspx

    http://drdobbs.com/cpp/184403942

    or , in .NET 4

    MEF

    http://mef.codeplex.com/

    http://csharperimage.jeremylikness.com/2009/11/mef-build-plugin-in-under-10-minutes.html

    Wednesday, June 15, 2011 1:42 AM
  • User-1465674731 posted

    Thanks for your reply ignatandrei,

    What i mean by plugin/plugout is we should be able to add or remove any module in the project and application architecture should support that, so the question is how can we do this in 3-tier architecture.

    Wednesday, June 15, 2011 1:53 AM
  • User197322208 posted
    please read previous links and ask again
    Wednesday, June 15, 2011 3:39 AM
  • User-1465674731 posted

    Yes Ignatandrei i have gone through the link, that is talking about developing Plugin in .Net, what i feel that we can develop small plugins and deploy it in your applicaiton.

    What do you think we should develop each of our objects (Employee, Leave, Appraisal, travel...etc) as a plug in in one HRMS solution, and how it will be done in 3-tier architecture.

    Wednesday, June 15, 2011 4:42 AM
  • User197322208 posted

    What do you think we should develop each of our objects (Employee, Leave, Appraisal, travel...etc) as a plug in in one HRMS solution

    You can create a basic HRMS solution base on interfaces IEmployee, ILeave, IAppraisal, ITravel.

    Then you can load or not the concrete classes Employee, Leave, Appraisal, travel according to the user licence.

    Wednesday, June 15, 2011 6:32 AM
  • User1399096257 posted

    Hi Nizam,

    As per your requirement best possible architecture is Service Oriented or Service Based Architecture (SOA). Within SOA plug in/out & modular feature is implemented by using concept of Enterprise Service Bus (ESB). Using ESB we can ON / OFF any service. We generally use this for large applications and also it is little complex &  costly. 

    Since you already have developed your application in 3-tier arch. You need do some changes using Visual Studio:

    1. Separate Presentation layer, BAL &  DAL in different projects. Put Business Entity (entity classes) in a separate project and provide its ref. to PL, BAL & DAL. You need to provide BAL ref. to PL, DAL ref. to BAL. Check project/solution properties to generate different DLLs for different project. Then on publish you will have separate DLL for each project. Now you may require to do some minor change in code in calling function or class references.  

    -- After doing this you can do what you explained in your question. Now you can maintain different versions of your DLLs. So in order to maintain versions you would need to generate strong name & register dlls.  So during deployment you can refer different versions of DLLs by defining the version number in the config file.

    -- It will solve your current problem.

    In order to make your code more maintainable in future expose your BAL to PL using an Interface layer. You can call this as service layer. You will need to create a service layer between PL & BAL. this service layer will be created by interfaces and these interfaces will expose only those functions which is ready to use. In the image below just consider Service layer as a collection of interfaces which is implemented by BAL and used by PL.

    Consider service layer as interface

    If you required any sample code I can provide you. 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, June 15, 2011 11:45 AM