The ORM Foundation

 I’ve been meaning to post this on the forums for a while now, but I’ve just never got round to it. This isn’t actually an open-source model but I didn’t know where else to put this forum post.

Anyway, onto what ORM Dictionary actually is. If you simply create a new object role modelling file or a modelling project and place it in a folder somewhere on your hard drive each time you create an ORM, you quickly find that your ORM files become disorganised, and therefore hard to keep track of.

Instead, if you create a single C# Visual Studio console application (or any kind of Visual Studio Project), you can simply place your existing, or new object role models into the projects solution. The benefit of this is that all your ORM files will appear under the Solution Explorer in Visual Studio, under a single project. This helps to organise your ORM files and provide quick and easy access to all of your ORM files from within Visual Studio – and also enables you to load all of your files at once if you create a .sln file for your project.

A further benefit of this approach is that because all of your ORM files are under a console application, you can click on the ORM file in the Solution Explorer and generate the DDL for your file directly. This is instead of having to create a new project each time you want to generate DDL, which I find is a bit of an inconvenience.

If that didn’t make any sense, then I’ve also added a step-by-step process of how to make the ‘ORM Dictionary’ in Visual Studio 2010 below.

1. Create a new Console Application project in Visual Studio
2. Give the project a nice, memorable name
3. In the Solution Explorer right click on your projects name then go to Add > Existing Item…
4. Select an ORM file you’ve created that you want to attach to the project
5. Repeat steps 3-4 for all your ORM files
6. Now you have easy access to all your ORM files, and can create new ORM directly by right clicking on the project name in the Solution Explorer and selecting Add > New Item

Also, once finished, your projects solution should like something similar to this…
http://i48.tinypic.com/17xwys.png

I presume some of you already organise your ORMs like this, but for those of you who don’t, I definitely think it’s worth it :)

 I do the same thing using a c# console app b/c it has a very small signature and I can focus on just the data model.  Only thing I wish was that I could combine my orm models and maybe distinguish the different fact types and object type into their own sections by schema name.  And maybe where two or more different schemas reside in a single fact types and are combined then maybe in a future version make that like an interface schema fact type. This would be especially useful for managing large numbers of entities which utilize different schemas.

Been doing the same thing for six years now... <https://github.com/cjheath/activefacts/tree/master/examples/norma> I use several projects under one solution. In addition, each client gets their own solution, so as not to mix things up.

Marc, CQL is excellent for breaking large models down into small re-usable fragments. A project with a current client has 55 separate CQL files (one sub-topic each) and generates relational schemas and data tier code for about 100 tables. About half of the CQL files (which each correspond to a single diagram in the ORM version) are completely generic - I could take them from this employment-solutions company and use them in insurance, or banking, or whatever, because it's broken down into many separate topics, all individually composable.

If you have a mind to give CQL a fly, you can install ActiveFacts (open source) and generate CQL from your existing ORM models; none or not much re-work wil be required.

The reason for having multiple files in the first place is to clearly define separate business processes and tiers of functionality.  I would definitely be interested in using tools that can not only organize separate business processes but also explain how they might connect up.  I know I can make a high level tab in the Norma tool which explains that interface but it is limited and a little archaic b/c it would require lots of notes to explain it only at a high level.

But what would be useful is not have to create separate files at all but just use the schema name to separate the different business processes or even have a sub schema for different derivations and then where an interface between schemas occurs (fact type between schemas) make those special business processes (like a different color for those face types) b/c usually security, authorization, roles, logging, redo, undo, views, triggers, transitions, access, even data diode transitions and are usually aspects that change when going between separate business processes.  Especially when going from an intranet, extranet or internet situation. 

Clifford, I did try to install that tool but had some problems on my Windows machine.   I'll have to try it again, maybe I didn't use as admin b/c I ran into some security issues.  Also I have a Linux box which I can try it out on.

mnnoon:

I did try to install that tool but had some problems on my Windows machine.