Greg: I am thinking that one of us is missing the other's point here because we seem to be talking past each other. RAP does not presume to implement any particular functionality any more than a complier presumes to. RAP's entire purpose is to create applications (or frameworks or whatever) in a highly consistent manner rather than in the handcrafted manner that is pervasive today. To argue against the use of RAP (and everything like it) is analogous to arguing against the use of compilers and claiming that we'd be better off building and using application-specific libraries written in assembly language.

RAP is intentionally application-agnostic like a compiler is intentionally application-agnostic. It has to do with systemetizing the plumbing of applications, not defining their functionality.

Whether you are writing a "framework" or an active library component (like Microsoft's logging or authentication libraries that have their own databases), or whether you are writing apps that make use of those things, somebody somewhere has to actually be designing schemas, coding databases, coding data layers, building business rules and writing user interfaces. We have a choice here: we can code those things by hand (the "whatever the team comes up with" standard) or we can code them mostly automatically with a degree of precision that no human team could possibly attain. RAP's purpose is to do that.

So RAP has nothing to do with subscribing to (or not subscribing to) the use of frameworks and libraries and patterns and practices, except of course that it is based on the .NET framework. You are perfectly free to use RAP to build database-based libraries using whatever patterns and practices you choose.

You've lost me here completely. Every compiler is a code generator. Would you advocate that we abandon compilers because of the possibility of a bug? Like a compiler, RAP generates hundreds or thousands of completely formed database and data layer routines and objects whose consistency and reliability would be quite beyond the capability of any human team to maintain. A RAP-generated database will contain precisely zero coding errors (and in the unlikely event of a bug, it would be easy to fix the bug and then truly be at zero coding errors). In constrast, I have never seen any significantly-sized human-maintained database that I would estimate to be anywhere near that level of error freedom.

There is nothing about RAP that precludes the use of principles, patterns and practices. The upper tiers of RAP in fact implement a strict MVC model, so RAP has a built in "pattern". Like MVC itself, RAP's implementation of it is application agnostic and so it is applicable to essentially all apps. RAP also contains its own highly reliable ORM, which is a library of sorts (a ton of code that people don't have to rewrite every time) that does a far better job of database interaction than I would expect any human team I've ever worked with to be able to generate.

So I guess I'm missing the point. There is nothing about the use of RAP (just as there is nothing about the use of compilers) that would preclude anything you're talking about. All the things you're talking about have to be implemented using some technology and RAP presumes to improve that technology (much as compilers are regarded as an improvement over assemblers).