CODEWITHSUNDEEP
asp.net-mvcasp.net-mvc-3linq-to-sqlnaming-conventions
arserbin3
arserbin3

Reputation: 6158

Multiple DBML models best practice for class names

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:

**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:

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:

Intranet Database:

CRM Tool Database:

Upvotes: 0

Views: 822

Answers (2)

mattkab
mattkab

Reputation: 738

If I understand your problem correctly, you have two additional possible solutions:

  1. You can modify the namespace of the entities generated by the DBML. Assuming you use T4 templates to generate them, you can right-click on the *.tt file, and go to properties. There is a namespace property that you can set to your own custom, and therefore unique, namespace:

    • MyCompany.MyProject.DataModels.Live
    • MyCompany.MyProject.DataModels.Intranet
    • MyCompany.MyProject.DataModels.CRM

  2. A second, similar option would be to have each dbml and the generated classes be contained in their own project, and their own namespace associated with it. So in this case you would have three new projects:

    • Data.Live
    • Data.Intranet
    • Data.CRM

    You would then add a reference to the projects when you want to consume them.

    The benefit to this, in my opinion, is that it is very likely that tomorrow you could have a project that needs to reference Live, CRM, and a brand new database. In this case you would simply take a dependency on the projects you've already created (binary, or code -- my preference is binary, but YMMV), and that part of this 2nd project is complete.

In my opinion, do not decorate you classes (your option 2). That will be very difficult to maintain. There is nothing inherently wrong with your option 1, and I have done that as well, but for most of my current solutions I create projects for the reusability factor.

Upvotes: 1

Kyeotic
Kyeotic

Reputation: 19857

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

Upvotes: 0

Related Questions