Interested in POCO LINQ?

I've been investigating using LINQ to SQL with a POCO approach. (POCO = Plain Old CLR Objects.) My ideal solution would be something like this:

1. Entity classes are simple enough to be hand-written (no need to generate them with SQL Metal or VS 2008)
2. Mapping is easy (no need to manually map every property via attributes or external XML)
3. Lazy-loading works
4. Bi-directional relationships work (update one end, and the other is synchronized automatically)

The last two points are the most problematical. In LINQ to SQL lazy loading requires the use of EntitySet and EntityRef. However, it's not easy to use those classes in hand-written code. In fact, it is generally recommended to dispense with these classes if you want to "go POCO". But that deprives you of lazy loading. You also lose out on Linq’s support for bi-directional relationships, because it is also based on EntitySet and EntityRef.

I want a solution that supports all four goals outlined above. [Update: here it is]

Question: If I can find one, would you be interested in it?

If enough people say yes (either in comments below or via email), I’ll try to post something within the next few weeks.

I understand that knowledgable people have said this can't be done. I respectfully disagree ;-) Based on work so far, I’m satisfied that it can be done.

Update: The idea would be that you'd hand-write .NET classes, according to a few simple conventions. Do that and you'd automatically get working bidirectional relationships and lazy loading, plus automatic runtime generation of the correct mappings. (You'd never use SQL Metal or the Visual LINQ designer.)

You could also generate the database if you want. (I.e. the usual model is generate-code-from-database; this would allow (but not require) generate-database-from-code). If you use TDD, you could create and test the objects using TDD (running in-memory tests) and then generate the database.

Other simple little benefits would be: e.g. could have one file per class (which you can't with MS's generators); could put comments on the properties of those classes (which you can't with MS's generators, as far as I can tell), could put your own attributes on the entity/domain object classes, e.g. for attribute-based validation frameworks (again, you can't with MS's generators), entity classes compact enough to actually read them ;-)

---

Footnote: In this post I’m talking specifically about LINQ to SQL. I know that there are (or soon will be) several fine independent ORMs that use the LINQ language features to create their queries, but execute those queries with their own backend. A number of these products support POCOs but, for my current project, I need a solution for the full Microsoft "stack" - including LINQ to SQL.

Update on Persistent Iterators

Some time ago I wrote about implementing workflow with persistent iterators. This is just a reminder (in case you missed it in the comments on the original post) that Microsoft are going to change the implementation details. Until they announce details of the change, we can't be sure whether the technique I posted will work in future versions of C#.

Mads Torgersen, the C# Language PM, wrote:

We are likely to in fact change the way iterators are implemented in future versions. That said, we might be able to implement a serialization format that would work across such future changes. I agree with you that this would be a very useful feature.

If you want to use this technique in future versions, head over to this page and vote for it.