Combench-O/R er Terminator?

Today, I took a special look at combench. Other features are skipped for the moment, but I was shocked by the direct integration of its language into SQL !!! Not to mention whether its SQL syntax features are powerful, because these can be gradually enhanced. What I like most is that it creates the Northwind by referencing the fundamental database structure. dll, you can directly check the compilation period of the object class (in fact, you can check it dynamically during editing ).

You know what this means for our database development! Refactoring, eliminating hard coding, readability, improved development efficiency, and unrelated to the database platform... O/R Mapper is more elegant and must be mapped. It is impossible to shield developers from understanding the database in a slightly complex system, the functions of O/R Mapper to separate business layer and data access layer do not conflict with each other. The DAL layer and BL can still exist, but life has suddenly become much better.

It can be said that from the perspective of a Database Developer, this feature of combench is exactly what I need. It seems that Andres Hejlsberg mentioned similar features in C #3.0, which is good, this is what we want.

 

For many people, the irreplaceable nature of a stored procedure is not its performance (How much can compilation optimization improve its performance ?), The difference lies in its compilation check. When you change the name of a table, you can easily know which stored procedure references it (the premise is that you cannot write dynamic SQL ), the SQL support of combench saves this advantage without using SP.

Of course, for the moment, only simple SQL support cannot replace SP, but the appearance of combench makes us see the bright future. O/R Mapper, when can I discard it completely? In the maintenance of the RelationShip and the ability to check the database objects during the compilation period, I would rather not maintain the RelationShip. Of course, compose does not contradict the RelationShip support. When such code:

Customer c = (Customer) Session. Load (typeof (Customer), "001 ");

Quilt

Customer c = select Customer from DB. MERs where code = "001 ";

What I saw was a simple and happy replacement.

In addition, for the current OCL, how to support it is to write expressions in strings or construct expressions through functions, so in the latter, some solutions Add the public const field describing the attribute name to the Entity class to construct the expression, but none of these are what I want. How to construct a query is far less readable than SQL, because SQL is the best language to describe and manipulate RDBMS.

I have always been a pessimistic. Although I am writing my own O/R Mapper framework, I still don't like it. To thoroughly change the current availability of O/R Mapper, it should be a sudden change in O/R Mapper, a direct CLR support like combench, or a unified system of object-oriented databases, integrate the first two into one?