"Importing" my existing classes to a dbml?

[Andy]

Hi,

I'm currently moving (slowly) to use Linq to Sql to replace my custom
data access layer. Fortunately, my DAL worked very similar to L2S as
far as the use of classes goes; each table is decorated with
attributes that tell my DAL how to do what it needs.

At first glance, it seemed all I had to do was slap the Table and
Column attributes onto my classes, and I could use both Linq and my
DAL as I transition.

I'm now at the point where I'm creating associations and going to be
using Linq to update data, not just read it. I hit a problem, which I
think was caused because my backing field for the ONE side of a
relationship was MyTable, not EntityRef<MyTable>. Ok, I can fix that,
I've only done a few classes. Now I'm looking at the EntitySet side
of things. Here it seems more complex; initially I had simply the
field for EntitySet<MyTable2>. But it looks like other code is could
be needed, such as specifying actions for insert and delete and
implementing IPropertyChanging and IPropertyChanged.

So.. is there any way to automate getting this code in? Do my data
access classes HAVE to be in the Dbml.designer.cs file, all in the
same namespace?

What are my options here?

 

[Rick Strahl]

So.. is there any way to automate getting this code in? Do my data
access classes HAVE to be in the Dbml.designer.cs file, all in the
same namespace?

If you're building your attributes and classes by hand you can store the
resulting class
anywhere. You don't need a dbml file at all - that's just the designer file
with the
..designer.cs being the final output the compiler runs against. So if you
don't use the
designer ditch all the related files and just store in myEntities.cs file.

As to automation - well you're on your own there. Either you use the tools
that
come in the box or you manually do it. There are also some CodeSmith
templates
that might get you what you need with a litlte more control than SqlMetal...

+++ Rick ---