In my situation, my company services many types of customers. Almost every customer requires their own Business Logic. Of course, there will be a base layer that all business logic should inherit from. However, I'm going back and forth on architecting this--either in one dll for all customers or one dll for each.
My biggest point of contention deals with upgra开发者_开发百科ding the software. We have about 12 data entry personnel that work with 20 companies and it's critical that they have little down time. My concern is that if I deploy everything in one dll, I could introduce a bug in company A's logic while only intending to update Company B's logic. I believe I could reduce the risk if each company's logic had their own dll, so then, I could deploy Company B's update w/o harming Company A's. -- I will be the only one supporting this.
That said, this also seems like a nightmare to manage 20 different .dll's -- that's for the BLL alone. I also need to create a View layer and ViewModel layer. So, potentially, I could have 20 (companies) * 3 (layers) which would equate to 60 .dll's.
Thank You.
If "customer comes first" then you must reduce the likelihood of a bug in one customer's code affecting another customer. Therefore more DLLs. However, you can look at saving some headache: is there really a need to separate business logic, view layer, and viewmodel layer into different assemblies? Sure, you want to separate into different layers of code for maintenance, but is there a strong reason for taking that logical file separation to a physical assembly/DLL separation?
精彩评论