Question

I have a Client/Server application, where the Client and Server have some common tables (which are kept in synchronisation as part of the application).

We currently store these tables (i.e. FileDetails) in a Shared.dbml file. Until now, any stored proc that returns a result of set of FileDetails, has been placed in the Shared.dbml (even it is a Server-only) SP.

I released that the LINQ to SQL supports a Base Class property on the DBML, and I thought that perhaps I could have a Server.dbml, that extends my Shared.dbml. In theory this would give me a ServerDataContext with all the shared tables and SPs, as well as the server-specific elements. Normally in the SQL designer I would drag and drop the SP, over the FileDetails table to show this is what was returned, however as the class is in a different DBML this is not possible, and in the XML I don’t think the ElementType IdRef=”1″ approach will work (as the ref needs to point to another file)

I found I can get around that problem by editing the XMLs return type manually:

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

My question is, does anyone have any experience with this kind of approach, and could point me to further resources? Are there any obvious drawbacks to it (other than than manual XML updates)

All feedback welcome

Answer 1

You could inherit from your datacontext. However in your new datacontext you wouldn’t be able to use the linq designer you would have to code things out manually.

Is there any reason you don’t want two datacontext?

Inheritance and LinqToSql don’t play nice together in general. If you have a deep need for it you should look into another ORM like NHibernate.