Missed opportunities with MSchema
- I just found out about Oslo the other day and it seems like it has incredible potential. However, the more I use it, the more wasted potential becomes apparent. The Oslo FAQ attempts to stress that the Oslo repository is not yet another database, but it doesn't seem to provide much to back that statement up. That's because right now, there isn't anything to back that up.
Currently, compiling a .m file spits out a SQL script and an .mx image to load into the repository. Once it's in the repository, however, there really isn't anywhere to go from there. The mapping from MSchema to DLINQ and EF/ELINQ is awkward at best and using those tools essentially amounts to rewriting the entire model in a different language (DBML or EDMX). This obliterates the advantage of modeling upfront with Oslo. Moreover, the Entity Framework redefines "overengineered" - it's inordinately difficult to work with, is missing a large share of functionality even present in DLINQ (WHERE IN and enum support come to mind), and requires truly massive and redundant configuration files. It isn't the way to go.
Imagine if the MSchema compiler not only put out a SQL script but also a .NET assembly. Modules would be mapped to namespaces; types would become classes and extents could be accessed from a central Repository object. A single MSchema file could be converted into precisely synchronized database-side and application-side models and the Repository would become not "just another database" but a lightweight object persistence store for .NET. Such a system would turn Oslo from the toy it is now into a powerful engine for developing data-driven apps not just quickly but verifiably.
However, right now, none of that is present. The current system is totally disjoint, and all evidence shows that no plan exists to change that. I hope it won't stay that way forever - it would be terrible to see such an awesome platform wasted away.
所有回覆
- Hi,
>>Currently, compiling a .m file spits out a SQL script and an .mx image to load into the repository. Once it's in the repository, however, there really isn't anywhere to go from there.
The Quadrant tool will allow you to "see" the structural models you have deployed in the management database and interact with those models. Quadrant was in very erly developmen stages at PDC, and the PDC build did not allow this, but future versons should.
>>A single MSchema file could be converted into precisely synchronized database-side and application-side models and the Repository would become not "just another database" but a lightweight object persistence store for .NET. Such a system would turn Oslo from the toy it is now into a powerful engine for developing data-driven apps not just quickly but verifiably.
I've also thought about this. I think we have to keep in mind that Oslo is still in its early stages of development, there will be a lot more functionality as we progress.
There are some pretty cool ideas here:
http://www.douglaspurdy.com/2009/03/20/mservice-a-dsl-for-restful-services/
http://www.douglaspurdy.com/2009/03/21/mservice-part-ii/
http://www.douglaspurdy.com/2009/03/29/mservice-part-iii/
Regards,
Alan
BloggersGuides.net Hi,
A feature that is, for all intents and purposes, useless. Do you expect the customers of a company to go fire up Quadrant and enter orders directly into a database? A database is useless without an application in front of it; the main problem at hand is shuttling data in and out of the database in a clean but performant fashion. Quadrant does nothing to fulfill this. Defining database schemas is not some academic exercise for "information architects". It's what happens when a real app needs to store real data. The oh-so-critical gap between these two needs to be bridged, and fancy graphical designers and specialist tools will not at all accomplish this.
>>Currently, compiling a .m file spits out a SQL script and an .mx image to load into the repository. Once it's in the repository, however, there really isn't anywhere to go from there.
The Quadrant tool will allow you to "see" the structural models you have deployed in the management database and interact with those models. Quadrant was in very erly developmen stages at PDC, and the PDC build did not allow this, but future versons should.>>A single MSchema file could be converted into precisely synchronized database-side and application-side models and the Repository would become not "just another database" but a lightweight object persistence store for .NET. Such a system would turn Oslo from the toy it is now into a powerful engine for developing data-driven apps not just quickly but verifiably .
I've also thought about this. I think we have to keep in mind that Oslo is still in its early stages of development, there will be a lot more functionality as we progress.
There are some pretty cool ideas here:
http://www.douglaspurdy.com/2009/03/20/mservice-a-dsl-for-restful-services/
http://www.douglaspurdy.com/2009/03/21/mservice-part-ii/
http://www.douglaspurdy.com/2009/03/29/mservice-part-iii/
Regards,
Alan
BloggersGuides.net
MService sounds somewhat cool, but it's far too simplistic for the vast majority of cases. Rarely would anyone want a barebones REST site that sticks raw data straight into a database; rather, a friendly user interface and more sophisticated behavior is nearly always necessary. This, of course, is what ASP.NET MVC is for, and MService is no substitute for it. However, no *real* solution exists for accessing repository data through .NET. Critical features in Microsoft products, even free ones, are removed far more often than they are added. Once the ship deviates off course, little can be done to bring it back on track. Crossing one's fingers and continuing to hope, however, is not an option.- This is the danger with engaging early with bits, people can get confused by the differenting state of various pieces and conclude that the overall story doesn't fit together.There is a complete story here for .NET developers and it is not disjoint. You just haven't seen it yet, as we are still working on it and we have a lot of work to do to align this with things like EF/EDM.In terms of things like MService, you can think of that as part of ASP.Net MVC, not some seperate piece. What you saw was defining a model in M and getting a REST service from it. Just like Rails.If we do our job right, you can expect to access this same model with a MVC controller written in C# trivially.We are spending a lot of time and effort working through this now.
- > Do you expect the customers of a company to go fire up Quadrant and enter orders directly into a database?
No. It's the *model* of the ordering application that goes directly into the database. Then, generators pull that data out and manifest the application in various ways. For example, complete code generation, code skeleton generation, configuration information for a pre-built framework, cfg info for a complete app, etc. - > Just like Rails.
Doug, I think many in the Microsoft ecosystem that are confused are so because the model-driven world is new to them.
The above is one of the very few references I see to existing technologies that show many of the Oslo concepts. Perhaps referencing them more often would clear the matter up.
As for them being competing technologies, there really isn't anything out there today that covers the totality of what Oslo will more than likely RTM with (nor the seamless integration with Visual Studio to production. Microsoft excelled in doing this with embedded to enterprise like no other. I'd expect Oslo will bring the scattered paradigms and practices out there, exhibited in a variety of products, technologies, frameworks and practices, into a single umbrella as it did before with embedded to enterprise).
I won't post example references here, this is your site. Just my $0.02, Microsoft should be referencing where a lot of the modeling/etc. is going on for the Microsoft ecosystem to get a better idea. When the ecosystem understands those tools, plays with them some, their feedback will help the Oslo effort IMHO.
