The ORM Foundation

Hi there,

While there are only 4 posts here, I figured the ORM Masters would reply to my lonely post.

I am currently taking Everest's Advanced DB Design class and have become pretty fascinated with ORM, albeit still a novice. That doesn't mean I can't dream.

I was thinking about starting a series of articles for beginners to get acquainted with ORM. I know there are those out there that are working on novice ORM books which I think will be incredibly helpful, but I think there could be more in the way of beginner tutorials that are accessible to a lot of people. I don't know how many of you follow online development sites like NetTuts, SitePoint, etc. but those are prime places to do a series like this. Screencasts, articles, tutorials, sample models, etc. Maybe even a wholly dedicated site ala http://asp.net (I was thinking: "Hooked on ORM").

Anyway, that was "Idea #1: Making ORM More Widely Available to Newcomers." The second idea is the hardest but I would like to be involved in it. That is to improve the UI and UX of NORMA. I was contemplating creating a web-based ORM modeler but the more I use NORMA the more complex it seems. Besides, why reinvent the wheel?

So, my questions are these:

1) Is NORMA separated enough (Data, Business, Presentation) to allow a different or additional presentation layer? Think web-based or perhaps a WPF application.

2) Is NORMA being extended to work with VS 2010? And, if it's not, I think it would be good to revamp the user experience for VS 2010 to take advantage of its richer graphical features. If it is, I'm interested in what's being done.

For me personally, I would be interested in pursuing one or the other, and to me it makes more sense to pursue 2) because there are a lot of pros to tying NORMA into the IDE (wizards for generating DDL, tie-in to Entity Framework, etc.).

Is the NORMA code loosely coupled enough to allow for a different approach to UI using VS 2010? For example, could I fork the project and create "my own" VS 2010 interface with all the existing code? My fear is that I wouldn't be very good at writing all the ORM logic myself (hence me not feeling too hot about rolling my own ORM modeling), but I do feel more comfortable creating a UI layer.

I don't consider myself any kind of UXpert, but I do feel NORMA could be improved in many ways... and it would be fun to try and contribute to that, even just on my own for my own learning.

Hi Kamran,

Thanks for your post. I'm pleased to hear that Gordon's work is bearing fruit.

On point 2: Work is under way to make NORMA available under VS2010 - probably within the next few months. 

Regarding your "separation" question - I'll leave it up to Matt to comment.(He is extremely busy so it may take a while)

Ken    

Kamran,

I also find NORMA quite slow to work with, and following up on my work with the Constellation Query Language, have made good progress towards a fully web-hosted ORM2 diagram editor (APRIMO). By "good progress" I mean that the ORM2 visuals and mouse/keyboard interaction is complete, encompassing almost everything NORMA is capable of showing in the diagram pane. APRIMO has a mouse interaction model which I believe to be much superior to NORMA's (which is rather constrained by Visual Studio and the DSL tools; not separable as you had hoped). The area where APRIMO needs further work is in AJAX-enabling it to a back-end application, which will be built in Ruby using the ActiveFacts tools and metamodel. I'm exploring various COMET approaches with asynchronous behaviour to maintain interactivity and support collaborative model development. With AJAX enablement will come multi-lingual verbalisation and many of NORMA's other capabilities, many of which are already present in the ActiveFacts back-end.

I'd be very happy to discuss the UX factors you desire in an ORM tool. I have a significant list of capabilities I desire, but haven't yet melded those into a proper UX design or plan. One advantage I have with APRIMO and ActiveFacts is that the entire codebase is under 15LKLOC, compared to NORMA's 800KLOC+. I've done all the "ORM modelling" and have both relational and object generation frameworks in place already, so if you wished to contribute, you'd be off to a flying start.

I do need to state upfront though that although CQL and ActiveFacts is FOSS, APRIMO is the core of my plan to capitalize on my last three years of work. If you wish to contribute, I'd ask you to respect that. If you wish to contact me privately, look for me at Data Constellation.

 This sounds exciting!

 One of the greatest troubles I've had in getting ORM some greater traction is the barrier of needing to have Visual Studio to really browse the diagrams.  The HTML report feature outputs the info, true, but not quite as well as actually poking around in th diagram. A web-based diagram tool, even a read-only tool, would be fantastic for helping to demonstrate the power of these models.

 I am looking forward very much to APRIMO!  If you're looking for someone to help test in, let me know?

Kamram,

Thanks for the post, and welcome to ORM.

subkamran:

Is NORMA separated enough

NORMA is heavily tied to the DSL tools components in Microsoft.VisualStudio.Sdk.Modeling assembly. Using this assembly outside of a machine with a VS install is a licensing issue, not a technical issue. VS was chosen because of the available utilities, from the windowing and command framework, to the ability to directly plug an .orm model into any other VS project. My view is that forcing a user with an existing project to abandon their framework and make the model the predominant overarching context for everything else is not realistic, but that there are many places where models can be integrated. Any time you need any data structure--from a DB to an XML file to a block of registry data--you should be able to describe that data with a model and generate the appropriate code.

The transacted object model framework provided by DSL was chosen specifically because it natively supports delete closures, meaning that delete propagation is calculated, marked, and notified before elements are removed from the model, not after. This allows us to determine what parts of a model need to be revalidated when an item is deleted. Without this supported, scalability and live validation would be constantly at odds with each other.

The presentation layer is a view on an underlying DSL domain model. VS2010 has a WPF view, but I have not had a chance to delve into it yet (see response on next bullet). There was a project a while back that opened a .orm file in a web page in a WPF view (sorry, I don't remember the location). Note that you can load any .orm file outside of Visual Studio and read/manipulate the object model the same way you would do internally. The code is:

using Microsoft.VisualStudio.Modeling;
using ORMSolutions.ORMArchitect.Core.Load;
//...
ModelLoader modelLoaderInstance = new ModelLoader(new ExtensionLoader(ExtensionModelData.LoadFromRegistry(@"Software\Microsoft\VisualStudio\8.0\ORM Solutions\Natural ORM Architect\Extensions", null, null)));
Store store = modelLoaderInstance.Load(ORMFILE);

You can then use the ElementDirectory and DomainDataDirectory collections off the Store to navigate the model. For example, store.DefaultPartition.ElementDirectory.FindElements<Diagram>(true)) will give you a collection of all diagrams in the model. You will be able to render this directly in WPF.

subkamran:

Is NORMA being extended to work with VS 2010

I've done initial investigation, and have a week blocked out this month for the port. I don't know if I'll make the release date, but I'll try. The initial issue is that the VS package registration is different, which will require setup and registration changes. The initial port will likely use the old DSL surface instead of the new WPF one, but getting things running at all on the new system is the top priority.

The actual drawing surface is a view on an underlying transacted model that has elements such as ORMDiagram, FactTypeShape, ObjectTypeShape, SubtypeLink, etc. that are in turn special implementations of Diagram, NodeShape, BinaryLinkShape, etc. from the Microsoft.VisualStudio.Modeling.Sdk.Diagrams assembly. The design surface code is relatively small, with the largest chunk of custom code in the FactTypeShape.cs file (~6k total lines). Much of the code here is for editor and toolbox interactions, dynamic color extensions, etc.

Eventually, we would like to get a full NORMA metamodel in .orm, and we're working through the formal derivation rule and dynamic rule extensions and corresponding generators we will need to model this complex of a system. This will give us the opportunity to generate to different systems, and make it easier to host the tool in other environments. However, even with the core model in place, the majority of the hand-written NORMA code is not in the model rules, it is in the editors surrounding the core, ranging from the Model Browser (a standalone system that has no knowledge of ORM or DSL) to the sample population windows, fact editor, verbalization window, and all of the other windows you see. Duplicating this in a disconnected web-based system and getting anything close to a responsive UI would obviously be a non-trivial amount of work. This code tends to be much less pattern-based than the shape and rule code, most of which follows a handful of patterns, so would be harder to replace.

If you'd like other details on how to get a dev build of NORMA going please contact me off line. Be careful: you need to run either a setup install of a NORMA or a locally built development version. They don't interact well.

-Matt