Rick,

>My point here is that if the abstraction is not high enough for you, you can always add it yourself in your library with a few lines of code. That way youo write it once and re-use it everytime. Again, my example is dataaccess. I can't remember the last time I ran ADO.NET code to run a database query or update operation - my business layer does that. And that code is nearly identical to the Fox code I use in my Fox apps.

There is a huge underestimated problem with writing your own classes for something the language should provide:

- It is your presonal solution to your perspective of solving problems, not by any means a standard solution that can be used by anyone.

- If there are bugs in it (and by definition there are), you'll be left on your own to hunt them down.

- As a result they tend to be buggy and inflexible.

- Everyone rolls their own and therefore you miss the basis to communicate with other developper on this abstraction level.

As much your classlib solution might be a solution to you, you cannot expect any .NET developer to roll their own on the same level or even know about your solution. In the same line I've asked KenL to replace the native RI builder in VFP9 with TaxRi which is more flexible, faster, more readable and consumes less lines. Though everyone can download it from the UT, you do not reach every developer who needs it. If the power really is in having classlibs, we should be programming in assembly.

The point indeed is granularity. From a database tool I expect highly usable building blocks, not hidden in classlibs (I can't remember when I ever looked into the classlibs MS did provide), but embedded into the language or framework. I'd expect native database DML (Set and record oriented) integration, easy databinding, etc. I want big building block geared towards the development of database tools. If I really need granularity or for whatever reason, we will look outside of the box.


>The argument of 'more code' is only true if you are coding at the language level for everything which for me at least is not option.

Again you can limit the code line differences, but you'll find that you'll be enhancing (developping and debugging) your classes for a long time each time if you encounter a slightly different problem if the classes are not granular enough (which always tends to be the case as they were intended to solve a particular type of problem). Maybe this is not a big problem if you are a brilliant developper which could invest a lot of time in building and testing such libraries, but this seldom applies to the average .NET programmer.

The matter indeed is abstraction and if the number of code lines are measured in the lines you idealy will have to program to solve a particular problem, you might be right, but I bet that in reality when doing this the first couple of years you'll be finetuning your framework classes as well, meaning that in reality the number of codelines programmed still is significantly larger than in a language where the code efficient functionality (like the DML in VFP) is embedded into the product.

Walter,