CodeBetter.com rips Oxite apart

I have not looked at the source, so cannot really comment, but disliked the use of Linq to SQL immediately. It is not scalable, and you know immediately that you are in workaround territory, with best practices not being adhered to.

Only a courageous architect would use Entity Framework at present, so hopefully they have things sorted out in VS2010. Linq is great with XML and POCO objects, and databases only for small projects.

I know it does not scale because I have written n-tier distributed applications, and the code with Linq to SQL gets very hard to maintain very quickly. It does not scale because like the Entity Framework it only addresses the connected environment (the next version will have disconnected capabilities.

This is an impediment because in this day and age of pc/laptop/phone/pda all disconnecting and then updating, an always connected ORM does not scale.

It also does not scale because it is dead. I would hate to be the one that pushed for Linq to SQL only to find out that support has been stopped. There is no way any architect worth his salt takes gambles with multi thousand/million projects with tech that lasts as long as the flavor of bubblegum.

Indeed blogs are relatively simple, but this is being touted as a CMS as well. At some point you will want to target the metaweblog API or have it disconnected, much the same that windows live writer does. It is when you need to do this, that the unecessarily complex workarounds creep in.

I also say this about dinner now, which is now de facto in Microsoft demos. It is a wonderful bit of tech, but daunting when you first countenance it. I like to keep things simple, and must have overwelming reasons to raise abstration layers. Too many people are afraid of SQL, which is a purer functional programming langauge than C# and it's lambdas. Once you know SQL well, all this => type syntax appears somehow inferior.

Also, because your object count is already inflated using Linq to SQL, it is just not so easy to understand. This is what I mean by scalability. It is good to begin with, but as soon as you want something a little more expansive, then  you have problems.

I also don't think there are very many programs written today that will not want to target web services in a disconnected manner, simple applications or not.

I do agree with code better over selling, almost sensationalist writing, but they to create a healthier balance. Criticism is good.

I'n not a complete blockhead by the way. I picked up a ten year old SQL book a while back, and was reading through it a few days ago. Pretty much the same stuff that was happening in 1997, is what is happening now in SQL. There is a consistency about it I like. Rather than the "use datasets, no use nHibernate or is that Linq to SQL or Entity Framework" mumbo-jumbo.

It just seems to me that tackling the impedance mismatch, i.e. a general purpose programming language, and a language only concerned with persistance like SQL just keeps on failing. For every new solution, there are as many drawbacks, and if you just bite the bullet, and head for the server i.e. SQL you end up in better shape. If all your data access code is in stored procedures, you have to worry less about concurrency on your client machine, be it paralled for loops or lambdas because this will happen on the server. Since SQL is a functional programming langauge, it will scale well on a many core server.

OK I know this is diverging from Oxite, but I prefer the old in this regard rather than the new. I'm just getting tired of new things that introduce more headaches further down the road.

I know you did not

You are correct about the monotonous coding, and people thinking it surely must be easier than this. EF could be good in a few versions time, we will have to wait and see.