There is actually a great way to separate them without jumping through hoops. I found a new code generation tool for LINQ-to-SQL that splits all of these parts into separate files which you could even put into separate assemblies AND you can still use the O/R Designer in VS2008 to make changes. The code re-generation process preserves both the designer changes and your code changes. It’s pretty cool. It’s called PLINQO. You can read more about it here: http://kevinlawry.wordpress.com/2009/02/18/does-linq-stinq-not-with-plinqo/

This is not true. The VS designer tool, and the corresponding command line tool Sql metal, do behave in the way you described. But there is nothing about Linq-to-sql that requires it to be this way. You can use your own persistence ignorant classes if you want. Alternatively, you can leave all the classes in the one generated file and then use partial classes to add behaviour to them. This is not a disadvantage since the classes are codegened, so having them generated into seperate files would not make them editable.

I too have had trouble trying to get the datacontext into a different assembly from the entities. However, once again I believe it is possible if you are prepared to walk away from the Linq-to-sql codegen tools.

Customer FindCustomer(int mainAccount)
{
using (Customer c = new Customer())
{
c.ObjectMode = ObjectModes.Search;
c.MainAccount.Value = mainAccount;
c.SetVisibleFields(c.ID, c.Name, c.TotalBalance);
c.FindAndLoad();
return c;
}
}

Best of all I could have added bunch of joins, sorting or added server side paging with the same kind of ease. I know Quick Objects guys are working on LINQ support and I am really looking forward to that. I haven’t tried ADO.NET Entity Framework yet but I can already do most of the stuff using Quick Objects very easily.

I am hoping soon I’ll review the Entity Framework soon.

Though I like LINQ to SQL much more than DataSets from what I have seen so far. And when using LINQ to SQL, you still can’t turn off your brain.

If you are talking “architecture”, services, abstraction and thelike, take a look at the ADO.NET Entity Framework, which is meant to be a full blown solution with much greater capabilities.

@tirat: “Real” real old code (if I had written it) would certainly not concat SQL statements with ‘+’, neither would it hardcode a dependecy between a SQL string and another pice of code like the indexed field access does. It would probably look like that:

Customer FindCustomer(int mainAccount)
{
using (DBHelper db = DBHelper.OpenConnection())
{
return db.ReadSingleRow(SELECT_CUSTOMER_BY_ACCOUNT, “MainAccount”, mainAccount);
}
}

Neat?

AJ.NET

Customer FindCustomer(System.Data.IDbConnection voConn, int mainAccount)
{
Customer c = null;
string lsSql = “SELECT id, mainaccount, name FROM tabAccount WHERE id = ” + mainAccount;
SqlDataReader rst = clsSql.ExecuteReader(voConn, lsSql);
if (!rst.Read())
{
c.Id = rst.GetInt32(0);
c.MainAccount = rst.GetInt32(1);
c.Name = rst.GetString(2);
}
rst.Close();
return c;
}

Customer FindCustomerLinq2(int mainAccount)
{
DataClassesDataContext dc = new DataClassesDataContext();
return (from cc in dc.CustomerLinqs
where cc.MainAccount == mainAccount
select new Customer()
{
Id = cc.ID,
MainAccount = cc.MainAccount,
Name = cc.Name,
TotalBalance = cc.TotalBalance
}).FirstOrDefault();
}