Question

Several of our apps use multiple databases from the example below – each in their own separate DBML file. The problem is, MVC by convention puts them all in namespace AppName.Models causing class name conflicts.

Which of the two options is the better fix and why:

1.) Putting them in separate namespaces. To keep stylecop/resharper happy, they would go in their own subfolder:

• /Models
• • /Live
• • • Live.dbml
• • • LiveDataContext.cs
• • /Crm
• • • Crm.dbml
• • • CrmDataContext.cs

**but now in code, all uses of them have to be Live.Customer and Crm.Customer to differentiate between objects.

EDIT: The other main downside of this, is that I see no other sample code from experts that use sub folders in the Models folder. On top of that, in order to keep the same naming for Helper file code reuse – even apps that only use one database would need a subfolder in Models, which I certainly never see people doing in MVC

2.) Prepending all object names in one or both DBML designers with a prefix. This is my current approach. The Live database has Customer and Order objects, while the Crm database has CrmCustomer and CrmOrder. They all stay in the same namespace and /Models folder. This, however has two main drawbacks:

• Quite a bit of prefix redundancy in accessing child objects: CrmCustomer.CrmOrders.First().CrmOrderType Marsha Marsha Marsha
• In other apps which only use one database, we often omit the prefix – and then during code reuse or Helper files we have to do a lot of find/replace. This is particularly evident in Helper files that get added to every app like error/activity logging.

So I’d like to hear from other experts which of the two strategies they use, or something else entirely. It seems like a pretty common occurrence to have at least some name conflicts between databases. Thanks

---

Example table names:

Live Database:

• Customer
• Order
• Address
• Phone
• Log
• 20 other tables

Intranet Database:

• Customer
• Order
• Address
• Phone
• Log
• 20 other tables

CRM Tool Database:

• Customer
• Order
• Address
• Phone
• Log
• 400 other tables

Answer 1

So, I question the design that leads you to needing two identical databases in code. That aside, I think option 1 is better. Here is my reasoning:

1. The code is more reusable. If you ever need to seperate either model into another project, or remove one, you don’t have to remove the prefixes anywhere. This offers clean separation.
2. Option 2 requires you to specify as well, you aren’t avoiding this. However, if any class needs to access only one namespace, you only need to specify at the using level, and not in every single reference to the code. In classes that need both, you aren’t avoiding the prefixses in either case. So option #1 wins out in the only case that matters.
3. I generally avoid type-prefixes as a rule. They are ugly.
4. Grumble, grumble, database design