<a href="http://encodo.com">Encodo Systems AG</a> started work on its metadata framework <a href="http://encodo.com/en/quino.php">Quino</a> in late 2007. We've used it successfully in many projects, from Windows desktop applications to standalone servers, Windows services and web sites. It has grown considerably since its inception and the core concept of keeping the focus of an application on its <i>metadata</i> has stood the test of time quite well. The recent article <a href="http://feedproxy.google.com/~r/FransBouma/~3/ydKUF3D6lsI/code-first-o-r-mapping-is-actually-rather-silly.aspx" author="Frans Bouma">Code-first O/R mapping is actually rather silly</a> recounts how the lead developer and architect of another popular <abbr title="Object Relational Mapper">ORM</abbr> LLBLGen Pro, has also recently "discovered" the benefits of the metadata-first approach. He writes, <bq>Starting with code in the form of entity classes is equally odd as starting with a table: they both require reverse engineering to the abstract entity definition to create the element 'on the other side': reverse engineer[ing] the class to the abstract entity definition to create a table and the mappings is equal to reverse engineering a table to a class and create the mappings. <b>[T]he core issue is that if you start with a class or a table, you start with the end result of a projection of an abstract entity definition</b> [...] What if that abstract entity definition which was used to create the class or table was in <b>a model which contained all of the domain types for the domain used in the software</b> to build? [...] it would give a couple of benefits: you can create overviews of the model and more importantly, changes in the domain can be applied directly into the model which then ripple through to classes and tables in the right form [...] (Emphasis added.)</bq> He describes the core tenets of Quino rather well: starting with the metadata avoids diluting the domain model with the limitations of a projection domain (classes, tables, etc.). This has been borne out by our experience working in exactly this manner for the last several years. The ORM in Quino is only a satellite component that leverages the centrally defined metadata just as many other components do. The programmer defines the metadata of the domain model and Quino provides tools to do many tasks automatically: <ol> Create or update a database schema Generate business-logic classes (primarily C# but it could be JavaScript or indeed any target language where code would benefit from strongly typed domain classes) Select/create/update/delete data in one or more databases Generate standardized user interfaces for multiple platforms Integrate with reporting engines and designers Generate UML diagrams ...and much more... </ol> I heartily encourage Frans to continue thinking in this direction. He will be rewarded greatly for it.