tags:

views:

77

answers:

3

If I want to work with an object and leverage LINQ to SQL what (if anything) do I need to add to my entity classes to ensure my application can talk to the data store? (keep out any discussion of repository patterns here as I'm just looking for what is required inside my business objects)

+1  A: 

Linq to SQL creates a POCO class for each table or stored procedure you choose from your data store, so as long as you are happy with the style of these created classes, you shouldn't need to add anything else.

Your entity classes will need a DataContext object. This object provides access to all of the tables of your data store, via the generated Linq to SQL classes.

A good introduction to usage of Linq to SQL can be found here: http://weblogs.asp.net/scottgu/archive/2007/05/19/using-linq-to-sql-part-1.aspx

Robert Harvey
Not sure he wants Linq to SQL creating anything, I think he wants to use it with his existing business objects.
mxmissile
Yeah - they aren't true POCO, either, since they need to be attributed.
Reed Copsey
You don't have to use attributes. You could use the XmlMappingProvider instead.
jrummell
+2  A: 

LINQ to SQL will create a (nearly) POCO class for each table or stored procedure. They are not pure POCO classes, however, as they still need to be attributed, with a minimum of the [Table] attribute.

For details, see MSDN.

FYI: Entity Framework 4 is going to add support for POCO classes.

Reed Copsey
Understood, I'm trying to compare what NHibernate requires and what LINQ to SQL requires (ignore that L2S is not a true ORM) - just to get some perspective.
Toran Billups
+3  A: 

Besides using the LINQ-to-SQL designer and having it create the "almost POCO" classes for you (decorated with a bunch of attributes for the mapping), you can also use an external mapping XML file (much like NHibernate) to achieve the same thing, thus allowing you to support "true POCO" classes without any additional attributes or anything.

See here for more information:

Marc

marc_s