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)
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
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.
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:
- External Mapping Reference (LINQ to SQL)
- Linq to SQL - Mapping Tables to Objects
- Using External Mapping File With Linq To SQL DataContext
Marc