When one of our primary solutions were first developed, when I was still a freelancer at the company, I decided to go completely RAD and the solution was build completely with Subsonic.

Subsonic is awesome, and I enjoyed it greatly - the RAD effect is amazing, and you really move.

The created architecture although build to RAD extremes, has grown out of our hands, and is to say the least, not at all maintainable. For a complicated solution, the "on the spot" generated data access without well defined tiers just doesn't cut it. Its fun building with it, but the solution is a nightmare to maintain - pure software development romanticism.

Its important to have fun while developing software, but it simply isn't fun having to do massive changes in a project that has virtually no division of responsibilities.

So our hope was to create a nice scalable architecture with Linq to SQL, and so I have been doing one proof of concept after the other combined with the MVC framework. I will save my worry about the DataContext and disconnected setups to another post, but focus instead on the problem of a data model of increased complexity having to function well with Linq to SQL.

Linq to SQL shares the wins and woes with Subsonic to a great extend. It lets you easily create a 1:1 mapping of your existing database schema to classes, and is well suited for prototyping, RAD development and simple static applications.

Linq to SQL works - for the common scenarios, and if you have a simple database, that is not normalized to a high extend - it makes perfect sense. But if you have a complicated and highly normalized database layout, you will truly face the O/R dilemma: You don't need a relational representation of data in your application, you want logical objects.

In enterprise scenarios you might even have multiple data stores, and a very competent and entreprenant DBA who keeps making changes to these to keep up performance and so forth.

So while Linq to SQL lets you build strongly typed objects from tables and views, call stored procedures that return strongly typed results, represent foreign-keys as strongly typed relationships, and extend the generated classes - you will be fighting the O/R problem if you want a neat and logical data representation, as you are rather strongly coupled with the schema of your database.

What we need are objects that correspond with those you would define in your use cases and er diagrams, not objects created with a 1:1 relationship with tables in the database.

We are not going to use Linq to SQL, but at the moment we a looking into the ADO.NET Entity Framework instead, which seems to fulfill many of our demands, but I will keep you posted on our progress.