Plusieurs fichiers DBML - partage de type?

Question

J'ai une application client/serveur, où le client et le serveur ont des tables communes (qui sont conservées en synchronisation dans le cadre de l'application).

Nous stockons actuellement ces tables (c'est-à-dire FileDetails) dans un fichier Shared.dbml. Jusqu'à présent, tout proc stocké qui renvoie un résultat d'ensemble de FileDetails, a été placé dans le SP Shared.dbml (même s'il s'agit d'un serveur uniquement).

J'ai publié que LINQ to SQL prend en charge une propriété de classe de base sur le DBML, et j'ai pensé que peut-être je pourrais avoir un Server.dbml, qui étend mon Shared.dbml. En théorie, cela me donnerait un ServerDataContext avec toutes les tables et tous les SP partagés, ainsi que les éléments spécifiques au serveur. Normalement dans le concepteur SQL, je glisserais et déposez le SP, sur la table FileDetails pour montrer que c'est ce qui a été retourné, mais comme la classe est dans un DBML différent, ce n'est pas possible, et dans le XML je ne pense pas le ElementType idref = approche « 1 » travaillera (comme l'arbitre doit pointer vers un autre fichier)

Je trouve que je peux contourner ce problème en modifiant les XMLs type de retour manuellement:

<Function Name="dbo.SELECT_FTS_FILES" Method="SELECT_FTS_FILES"> 
    <Return Type="ISingleResult&lt;DataTypes.FileDetails&gt;" /> 
</Function> 

Ma question est, Quelqu'un a-t-il de l'expérience avec ce genre d'approche et pourrait-il me diriger vers d'autres ressources? Y a-t-il des inconvénients évidents à ce (autres que les mises à jour que XML manuel)

Tous les commentaires Bienvenue

Answer 1

Vous pourriez hériter de votre DataContext. Cependant, dans votre nouveau contexte de données, vous ne seriez pas en mesure d'utiliser le concepteur Linq, vous auriez à coder les choses manuellement.

Y a-t-il une raison pour laquelle vous ne voulez pas deux datacontext?

L'héritage et LinqToSql ne sont pas sympa en général. Si vous en avez vraiment besoin, vous devriez vous tourner vers un autre ORM comme NHibernate.