Should I have one dll or multiple for Business Logic?

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?