none
Linq best practice: Multiple dbml files or one? RRS feed

  • Question

  • We just started a new project and want to use Linq to SQL. We saw the movies made some test cases and all is well.

     

    Now we have to decide wether we use one dbml file with the whole database schema in it, or make logical files to make diagrams more readable

     

    Some of the considerations:

     

    If a table is used in more than one dbml file (e.g. Users, ChoiceLists etc.), we have to rename the SQL Class: If choicelist is used in more files than we have RelationChoiceLists and ReportChoiclists which are pointed to the same SQL table in SQL Server (2005).

     

    And yes we know that if something changes in the DB structure we have to loop through all dbml files to reflect the changes.

     

    Almost every table has a Creator and Created a Changer and Changed fields, that a lot of relations!! We have to have this relations in de dbml in order to use strongtyped fields to display user information (all keys are sequential GUIDs and so Creator is a GUID). Maybe we could use some methods to get rid of all these relation line (from the user table to almost every other table).

     

    So what would be best practice: One dbml file, or more than one?

     

     

    Thursday, July 17, 2008 7:35 AM

Answers

  • I would personally go with one DBML file providing you do not have too many tables (400+). If your database has discrete sets of tables that are not linked then multiple DBML's are an option but I would not recommend having a table in more than one DBML with different names as you will soon run into odd issues where you want to assign one to another or get concurrency problems or even developers having to reproduce validation or business logic code against two different classes.

     

    [)amien

    Tuesday, August 19, 2008 9:20 PM
    Moderator

All replies

  • I would personally go with one DBML file providing you do not have too many tables (400+). If your database has discrete sets of tables that are not linked then multiple DBML's are an option but I would not recommend having a table in more than one DBML with different names as you will soon run into odd issues where you want to assign one to another or get concurrency problems or even developers having to reproduce validation or business logic code against two different classes.

     

    [)amien

    Tuesday, August 19, 2008 9:20 PM
    Moderator
  • Thx Damien,

     

    We started with multiple DBML files, but that was not workable after a while and led as you said to confusion.

     

    No we havve only one file. Micorsoft still has some work to-do and there's plenty room for improvement, not to mention some bugs. (adding in de designer file properties exposes this to intellisense, adding a partial class property elsewhere isn't, and so on..)

     

    Henri

     

    Wednesday, August 20, 2008 7:05 AM
  • Yes, being able to split the DBML into separate files would be a great feature to add and I'd personally like to add it to my T4 template code generator if I can figure out a good way to achieve it given the possible duplication of some entities between models (where associations exist).

    [)amien
    Wednesday, August 20, 2008 8:32 AM
    Moderator