Meilleures pratiques pour la gestion des fichiers Dbml Linq to SQL?

Question

Je viens tout juste de commencer à utiliser Linq to SQL, et je me demande si quelqu'un a une bonne pratique à partager pour gérer les fichiers dbml.

• Comment les maintenez-vous à jour avec la base de données?
• Avez-vous un seul fichier dbml pour toute la base de données ou est-il divisé en plusieurs unités logiques?
• Comment la gestion de ce fichier fonctionne-t-elle dans un environnement d'équipe?

Tous les autres trucs et astuces sont les bienvenus.

Answer 1

Avez-vous regardé SqlMetal? C'est officiellement pris en charge, bien que ne favorise pas trop. Vous pouvez l'utiliser pour construire dbmls à partir de la ligne de commande, - nous l'avons utilisé comme partie d'un db de l'intégration continue les mises à jour (assurez-vous que vous avez vraiment de la bonne séparation de code si vous faites cela, cependant, des classes partielles sont un sauveur - le dbml seront écrasés).

Si je me souviens bien il n'a pas tout à fait les mêmes caractéristiques que le modèle de concepteur de Visual Studio (je pense que c'poignées de pluralisation différemment). Il y a un bon post à ce sujet sur Ben Hall du blog.

Answer 2

Le fait que le concepteur L2S ne prenne pas en charge la synchronisation avec la structure de la base de données est une limite énorme dans mon esprit. Toutefois, un complément disponible fournit certaines fonctionnalités de resynchronisation:

http://www.huagati.com/dbmltools/

Malheureusement, ce n'est plus gratuit.

Answer 3

Depuis que vous avez demandé pour d'autres conseils et astuces pour la gestion des DBML...

Lorsque DBML fichiers sont actualisées à partir de la base de données, il y a certains paramètres de schéma qui ils ne ramassent pas, tels que par défaut les valeurs de colonne, vous forçant à changer manuellement le réglage. Cela peut conduire à des heures perdues à chaque fois que vous actualisez la DBML sans s'en rendre compte ou de se souvenir où vous avez besoin de faire des ajustements manuels, et votre code commence à tomber en panne.

Pour se prémunir contre cela, une astuce consiste à écrire un test unitaire qui utilise la réflexion pour vérifier le LINQ métadonnées pour ceux (manuel) des paramètres. Si le test échoue, il donne un message d'erreur descriptif, demandant à l'utilisateur de faire le bon changement pour les propriétés de la colonne. Ce n'est pas une solution parfaite, et il pourrait ne pas être pratique si vous avez de nombreux réglages manuels, mais il peut aider à éviter certains des principaux douleur pour vous-même et votre équipe.

Voici un exemple de test nunit pour vérifier qu'une colonne est définie sur auto-générer à partir de la DB.

    [Test]
    public void TestMetaData()
    {
        MyObj my_obj = new MyObj()
        {
            Foo = "bar",
        };

        Type type = MyObj.GetType();
        PropertyInfo prop = type.GetProperty("UpdatedOn");
        IEnumerable<ColumnAttribute> info = (IEnumerable<ColumnAttribute>)prop.GetCustomAttributes(typeof(ColumnAttribute), true);
        Assert.IsTrue(
            info.Any<ColumnAttribute>(x => x.IsDbGenerated == true), 
            "The DBML file needs to have MyObj.UpdatedOn AutoGenerated == true set. This must be done manually if the DBML for this table gets refreshed from the database."
        );
    }

Answer 4

PLINQO est un ensemble de modèles de génération de code générant LINQ to SQL. Il prend en charge la synchronisation avec la base de données et le fractionnement d'entités en plusieurs classes, ainsi que de nombreuses autres fonctionnalités qui facilitent l'utilisation de LINQ to SQL.

Consultez le site PLINQO à l' adresse http://www.plinqo.com ainsi que les vidéos d'introduction.

Answer 5

Voici un lien qui fournit des informations utiles sur les meilleures pratiques LINQ to SQL

http://www.a2zmenu.com/LINQ/LINQ%20to%20SQL%20Best%20Practice.aspx