I Get Tired of OOP Sometimes

I'm learning the ADO.NET Entity Framework particulars and I found this highly instructional ADO.NET Entity Framework Overview document => http://msdn.microsoft.com/en-us/library/aa697427(vs.80).aspx

In it I found a somewhat contentious paragraph describing the value of the client-views infrastructure required to stylize the consumption of the logical data model, using .NET code rather than database views.

An obvious question at this point would be why not just use traditional database views for this. While database views can abstract many of the mappings, often that solution won't work for several process and functional reasons: (a) many of the views are simply too complex to be generated and maintained by developers in a cost-effective way, even for some simple conceptual to logical mappings, (b) the classes of views that have the property of being automatically updatable at the store are limited, and (c) databases for core-systems in medium and large companies are used by many central and departmental applications, and having each individual application create several views in the database would pollute the database schema and create significant maintenance workload for the database administrators. In addition, database views are limited to the expressivity of the relational model, and typically lack some of the more real-world concepts of the Entity Data Model, such as inheritance and complex types.

I'd like to address this paragraph point by point since it is an obvious developer-helpless-against-the-database snippet of half truths that I think is troublesome too read, coming from my I-am-king-of-my-database point of view.

An obvious question at this point would be why not just use traditional database views for this.
This is a great question that was percolating in my mind the second I started reading about the client-view infrastructure. I love it when that happens.

While database views can abstract many of the mappings, often that solution won't work for several process and functional reasons: (a) many of the views are simply too complex to be generated and maintained by developers in a cost-effective way, even for some simple conceptual to logical mappings,
This has never happened to me even once. I've mapped dozens of domains to normalized database objects and all the necessary stylized views required from the nature of the conceptual model. Never once has it been too complicated or expensive to do. What I have experienced are conceptual models that radically change in structure because they never really represented whatever they were intended to represent in the first place. Such radical overhauls are problematic during development and possibly catastrophic post-production. However that is not a function of the shortcomings of the database tier to cooperate with whatever is asked from it. Also, I've seen conceptually illogical models that were overly complex and irrational to cover up the tracks of the modeling wing of the development team's incompetency - illogical irrational models are indeed too complex to be generated and maintained in a cost effective way. Perhaps, I've just never run into these simple conceptual models that can't be mapped to logical underpinnings in the database. My intuition says, show me such a model and my guess is that the model is ill-serving the application.

(b) the classes of views that have the property of being automatically updatable at the store are limited, and
This is true, sort of. A view can easily be constructed that provides an ambiguity on update, rendering this "automatic" feature unusable. However with Oracle, it's a simple matter to put an INSTEAD OF trigger to eliminate the ambiguity.

(c) databases for core-systems in medium and large companies are used by many central and departmental applications, and having each individual application create several views in the database would pollute the database schema
Huh? Every database platform has means to cleanly segregate database objects to eliminate this so-called "pollution". Calling something useful and perhaps necessary isn't really pollution, is it? It sounds like something the convenience store guy in Clerks would say, "You know the Customers are the only problem with this job." Also, when you have views in a database, the greatest asset of the database comes into play, physical integrity. For instance, if you have on of those core-systems, and the development team creates a new application that necessitates creating some views in the database there is no better means of knowing that changes to the core-systems physical structure have impacted this new application than when the view becomes invalid, obviously known from the data dictionary. This coupling is essential in my opinion.

and create significant maintenance workload for the database administrators,
If your database administrator is complaining about the maintenance workload for adding views into the database, please fire him immediately.

In addition, database views are limited to the expressivity of the relational model, and typically lack some of the more real-world concepts of the Entity Data Model, such as inheritance and complex types.
This is perhaps the most irritating statement. Listen up Mister and Missus Object Modeler: there isn't a single concept that you can model that the relational model can't persist. Period. If you believe otherwise, shed your belief immediately. Although you may not be able to express relationally your Masterpiece object model, that is reflection on you, not the massively stable and proven underpinnings of relational modeling. Just as a relational data guy like me struggles to create rich and useful conceptual object models realizes and admits where the rubber isn't meeting the road, me, so should you.