Using Data Contacts Generated by LINQ to SQL

Topics: General Discussion Forum, Service Factory Modeling Edition Forum
Feb 29, 2008 at 10:09 PM
I'm thinking about using the Web Services Software Factory in an application where we're already generating data contracts from LINQ to SQL. Is it likely that I woudl be able to integrate these LINQ to SQL data contracts into a solution where I'm utilizing the WSSF? I've read that the WSSF:Modeling Edition supports roundtripping between the model and generated code, so I'm wondering if I could expect to work with and integrate these LINQ to SQL-generated data contracts into WSSF.

Sorry about the broad question, but I'm fairly new to this and any advice would be appreciated.

David Madrian
Mar 27, 2008 at 8:34 PM
I am wondering the same question.
Were you able to get any guidance on that?
Mar 27, 2008 at 9:11 PM
Ok, so let's clarify some concepts.
First WSSF:ME does not support round tripping so you basically can generated code only from the models but you cannot uypdate/create the models from existing or manually updated code.
So according to above, you may not use LINQ2SQL to generated DCs and then update the model.
Now, since WSSE:ME is pretty extensible, is does support adding a recipe where you can import code defined classes or whatever you want into a model. You may find how to do that in the Extensibility Hands-on labs that can be downloaded from the home page.
Aug 20, 2008 at 8:52 PM
We have been using WSSF:ME for some time and it is a great help. More recently, we have started exploring LINQ, and LINQ2SQL in particular.

It looks like LINK2SQL can save a significant amount of development time, so the incentive to use it is huge. However, it confuses me when I start thinking about using it within the WSSF:ME architecture.

The .cs file generated with LINK2SQL (SqlMetal) contains two (maybe more) main types of artifact. First is the DataContext class, and second are the entity classes. The DataContext class is clearly something that belongs in the "Resource Access\DataAccess" project generated by WSSF:ME. The entity classes can be viewed as business entities, which means that it belongs in the "Business Logic\BusinessEntities" project. If the entities are generated with the /serialisation:Unidirectional option, they become data contracts as well. This provides another option... to put it in the "Service Interface\DataContracts" project.

We are a very small development team, and there is no time to start customising WSSE:ME at the moment. However, I would like to continue applying best (or at least good) practices in terms of the architecture of our applications.

Amongst my confusion, I have come up with one idea of how one can handle the situation:
- Generate the DataContext class in the namespace of the "Resource Access\DataAccess" project.
- Generate the entity classes in the namespace of the "Business Logic\BusinessEntities" project.
- Use the /serialisation:Unidirectional option to generate the entity classes as data contracts.
- Add the LINK2SQL generated code (DataContext and original entity classes) in the "Resource Access\DataAccess" project.
- Add my own partial entity classes, that are used to extend the generated entity classes, in the "Business Logic\BusinessEntities" project.
- Reference the "Resource Access\DataAccess" project in the "Service Interface\ServiceContracts" project to get access to the LINQ2SQL-generated data contracts.
- Reference the "Resource Access\DataAccess" project in the "Service Interface\ServiceImplementation" project to get access to the LINQ2SQL-generated data contracts.

A lot of what I am suggesting above feels wrong, but I have not been able to come up with something better.

Some good advice on the above issues would really be appreciated.

Kind regards

Johan Zietsman