Archive for May, 2010

Large models in LightSpeed 3.1 – Part 2

Tagged as LightSpeed

In a previous post, I talked about some of the issues that arise when you want to work on a large model in a visual designer, and some enhancements in LightSpeed 3.1′s filtered views feature to get around those issues. However, a model with filtered views is still a monolithic model. Sometimes you want to be able to split your model across multiple files. In a large system, for example, you don’t want the model file to become a bottleneck: it’s useful for multiple developers to be able to work on different parts of the model at the same time. It’s also good discipline to try to partition the model up into discrete subsystems so as to minimise coupling between those subsystems: this allows the subsystem models to evolve independently as requirements change and the domain is modelled in more detail or needs to reflect changes in the real world.

For example, in an order fulfilment model you might identify three major areas: orders, logistics and customers. Each of these areas has a potentially complex internal model, but has relatively few links to the other areas. They’re not completely isolated, of course: a customer has orders, an order has shipments. But they can be developed independently: you can refine the way warehousing is modelled without having to muck around with the way orders or customers are modelled; and conversely things in the orders or customers sub-domains may care about shipments, but probably don’t care about anything deeper in the logistics domain.

In LightSpeed 3.1, you can represent a semi-partitioned domain like this using linked model files.

The pattern of internal cohesion with relatively few external links is characteristic of a good sub-domain, and it’s the key to using linked models. Linked models need some external references — otherwise there’s be no point linking them! — but you want to minimise these, so that each linked model is as standalone as possible. Otherwise you end up having to jump between models to make changes, which cancels out the simplicity benefits of splitting the big model in the first place. Thus, in this example, we’d create three linked model files: Orders.lsmodel, Logistics.lsmodel and Customers.lsmodel.

With linked model files, we can represent each sub-domain in its own file, with entities that are defined in other files but needed for associations represented as entity links. Here’s how it looks:

Notice how PurchaseOrder in the Orders sub-model is able to link to Customer in the Customers sub-model and Shipment in the Logistics sub-model via entity links to the Customer and Shipment entities:

How do I link model files?

A LightSpeed designer model has a Name property, which you can see and edit by clicking on the model background and going to the Properties window. Two models with the same Name are linked. It’s that easy.

Really? It’s that easy?

Well, it’s almost that easy. There are a couple of extra rules. First, the Target Namespace settings of the models must also be the same. Most people leave the Target Namespace as the project namespace, so you don’t normally need to do anything here. Second, all but one of the linked files must have Is Linked Child set to True. It doesn’t really matter which one is the “parent” — it’s just that there’s some code that we have to generate once and once only, so we have to pick a file to host that once-only code.

But apart from those two wrinkles, it’s that easy.

Couldn’t you make it any easier?

Sure. If you’ve got a model which is starting to get a bit on the bulky side, you can right-click a one-to-many association that divides the model in two and choose Refactor > Split Model at Association. (If there’s no one single association which splits the model in two, you can select multiple one-to-many associations which between them split the model in two.) Enter the name of the new file, choose which half of the model you want to move into the new file, and Bob’s your uncle. The new file will automatically be given the same model name and target namespace as the “parent” file, and will be set as a linked child.

Also, if you use the Paste as Link command to create an entity link, it will check that the two files are linked, and offer to link them if they’re not.

So I have my linked files. How do I make a model that spans them?

As discussed above, linked models work best when there are relatively few associations that span files. If you have too many associations that span files, then you’ve not got good isolation between your sub-domains, and you’re likely to have to alter multiple files to make any change. But of course you need to be able to create some associations that span files. Here’s how.

First, identify the two entities you want to associate. Let’s say you want to model that an Order has a collection of Shipments. Order is defined in Orders.lsmodel and Shipment in Logistics.lsmodel.

Second, copy each of those entities in turn, and use the new Paste as Link command to paste a link to that entity into the other file. For example, select the Shipment entity in Logistics.lsmodel, press Ctrl+C to copy it to the Clipboard, switch to Orders.lsmodel, right-click the background and choose Paste as Link. You’ll see an entity link appear in Orders.lsmodel — you can tell it apart from a normal entity because it has a link icon and says “Link to” in its descriptive text.

Now do the same operation in reverse, copying the Order entity from Orders.lsmodel and pasting it as a link into Logistics.lsmodel.

Third, create the association in both files. In each case, you create the association normally, by selecting OneToManyAssociation from the toolbox and dragging an arrow from Order to Shipment. But you need to do it twice: once in Orders.lsmodel and once in Shipment.lsmodel.

Save the files and you’ll now find that your Order class includes a Shipments property and your Shipment class includes an Order property! Of course you can rename the ends of the association and set properties as usual — just remember to do it in both places.

Man, that’s like fourteen clicks.

I warned you! Cross-file associations aren’t as convenient as intra-file associations. If you’re having to create a lot of them, maybe you should be splitting your model in a different place. Or maybe linked models aren’t a good fit for your problem domain.

Yeah, but fourteen clicks. I’m a busy guy. Minesweeper doesn’t play itself, you know.

A lot of models are evolutionary: that is, rather than creating three .lsmodel files on day one, you’ll start out with a single .lsmodel file, and break it up about the eighteenth time someone else asks you when you’ll be finished with it. When this happens, you can use the Refactor > Split Model at Association command to partition the model. This will create the necessary links and “duplicate” associations. Three clicks and a few keystrokes.

We’ll also be working to improve this experience in future nightly builds.

Anything else I need to watch out for when using cross-file associations?

It’s important to realise that entity links aren’t really links — they’re more like references, and they can get out of date. If you change, say, the identity type of the entity, you need to update the links to that entity to reflect that change. Similarly if you have a cross-file association and you change its properties, you need to change them in both places.

Fortunately, LightSpeed does give you a bit of help with this. You can right-click a linked model and choose the Check Links command to verify that links and associations are up-to-date. For some inconsistencies, LightSpeed can fix the problem automatically: we can’t yet do this for all inconsistencies, but again it’s something we plan to improve in the nightly builds.

Where can I get it?

Linked models are supported in all editions of LightSpeed 3.1, in both Visual Studio 2008 and Visual Studio 2010. If you’re a customer, LightSpeed 3.1 is in the store now. If you’re not… well, normally at this stage I’d exhort you to download the free Express edition and give it a try, but the free Express edition is limited to eight entity types, which hardly counts as large model territory. But what the heck. We think this is a pretty handy feature for dealing with large models, and we’d love to hear your feedback on how we can improve it. So go ahead: download it anyway.

Add your comments
Posted by Ivan Towlson on 31 May 2010

Nightly news, 28 May 2010

Tagged as LightSpeed, News, Silverlight Elements, WPF Diagramming

We’ve not posted a Nightly News for a couple of weeks because we’ve been shipping releases rather than nightlies — see the Silverlight Elements 1.1 and LightSpeed 3.1 announcements. Still, here’s what’s new and not in those releases.

LightSpeed

• We’ve fixed a bug with ordering on group keys that were obtained by traversals.
• We’ve fixed an error that occurred in certain join-and-project scenarios if your entity had a property name that was the same as a property name that could be translated to SQL.
• Fixed a spurious warning relating to a designer option

WPF Diagramming

• Extensibility improvements to the connection remover and relocator
• Fixed a couple of cropping issues in image export

Silverlight Elements

• Resolved an issue relating to the order that properties were set in the Slider and DualSlider when using XAML

We’ve also got work in progress on our WPF Diagramming products and on porting some of the cool new Silverlight Elements controls to WPF. We’ll bring you an update on those as soon as they’re available.

Add your comments
Posted by Ivan Towlson on 27 May 2010

Licensing: Build servers and multiple developer machines

Tagged as General, News

Just a short post about our licensing policy – a scintillating topic for most, but hopefully a nice surprise for people looking at becoming a Mindscape customer :-)

We have started receiving more and more requests about what our licensing allows users to do. In particular – “Do I need a license for my build server?” and “I have 3 machines – my work PC, a laptop and my home PC, do I need 3 licenses?”. The answer to both questions is NO!.

Build machines
We’re a company of geeks for geeks – we like to see people using solid approaches to development which means we want to encourage the use of build servers and CI environments. Due to this, we are happy for you to install a copy of our software on your build box at no additional charge or requirement for more licenses. We also appreciate that build servers can get messy – for example, you may have on build server running build agents on several servers. These situations can get messy and confusing to people who just want to get on and build great software. So we keep it simple – a license is per human developer on the project (robots free of charge).

Multiple development machines
So you have multiple machines you work on? Lucky you! We also work at home, on laptops, on a desktop etc and know this has become a very common situation for developers. As we license per human being meaning you are more than welcome to install our software on the multiple machines that you use without additional licenses.

So the licensing is pretty simple – for every person who is working with our software, they should have a license.

Have a licensing question? Drop it on this post and I’ll be happy to help you out :-)

Add your comments
Posted by John-Daniel Trask on 27 May 2010

Large models in LightSpeed 3.1 – Part 1

Tagged as LightSpeed

Many people like to use visual designers to create domain models for a number of reasons: they save you writing boilerplate code, they make it very easy to see how entities relate to each other, and so on. However, when models become large, the visual representation can be hard to understand — there’s no way of “chunking” the model into sub-domains, and the relationships between the large number of entities can become a rat’s nest of overlapping arrows.

LightSpeed 3.0 provided some relief from this in the forum of a filtering feature. You could tag entities to identify the sub-domains they belonged to, and then you could hide everything except one sub-domain. (We provided several other filtering options too, which can be handy to know about.)

LightSpeed 3.1 builds on this by allowing you to save filters as “quick views,” so that you can easily return to them. So you can set up a filter to show, say, all entities tagged ‘sales’ and their associated entities, and save that as the Sales quick view. Then you can set up another filter to show all entities tagged ‘logistics’ and their associated entities, and save that as the Logistics quick view. And now you can switch into either of these two views with just a couple of clicks of the mouse.

To create a quick view, set up the filter in the normal way through the LightSpeed Model Explorer window (see the articles linked above if you’ve not played with this before). Then right-click the background, choose View and select Save Current as QuickView from the cascading menu.

To switch to a quick view, right-click the model, choose View and select the desired view from the list. Easy as that! (And if your filter is just a tag, you don’t even need to save the view — as you can see from the screenshot, tags appear on the View menu automatically.)

This isn’t the only improvement we’ve made to large model handling in LightSpeed 3.1. In particular, filtered views don’t help with concurrent editing, where two developers need to work on (different parts of) the model at the same time. We’ll talk about how LightSpeed 3.1 addresses this issue in Part 2. In the meantime, if you want to try out the new quick view feature, download the free LightSpeed Express edition today and take it for a spin!

Add your comments
Posted by Ivan Towlson on 26 May 2010

LightSpeed 3.1 released

Tagged as LightSpeed, News, Products

We’re pleased to announce the release of LightSpeed 3.1, a major update to our LightSpeed domain modelling tool and object-relational mapper. LightSpeed 3.1 rolls up an number of bug fixes and minor enhancements, and adds a number of major new features.

Visual Studio 2010 designer integration

Well, there’s not a lot to say about this — it does exactly what it says on the tin! You can now use the LightSpeed designer in Visual Studio 2010, with all your favourite features like database synchronisation, migrations, validation and so on just as they were in Visual Studio 2008. Since there’s not much to say, we’ll let the screenshot do the talking.

Breaking large models into multiple files

Large models are the bane of visual designers: as a model gets very large and complicated, the design surface gets crowded and sprawling, and it becomes hard to focus on the detail of a particular section. LightSpeed now offers the ability to break a model across multiple files using a feature we call linked models. If you use the same model name for models in multiple files, LightSpeed will merge them into a single runtime model. You can create associations that span files, and you’ll be able to use those associations at runtime just as you can use ‘normal’ associations between entities within a single model file.

By the way, if you’re one of the people who’s pressed us for this feature at a conference or user group or in the forums, you may have heard us saying that it was going to require support that was only in Visual Studio 2010. That would have been annoying, so we figured out a way to do it in 2008 as well. Good times!

Saved views in the designer

What if your model is large but doesn’t split nicely into linked files? LightSpeed 3.0 supported a number of filtering options whereby you could choose to view only a subset of your model — a particular aggregate, for example, or a set of entities related by a tag. However, you had to re-enter the filter each time you wanted to apply it. No more! LightSpeed 3.1 allows you to save these filters and access them from a handy menu. This new Quick View feature makes it easy to set up common views and convenient to jump between them according to the task at hand.

Class table inheritance

LightSpeed 3.0 supported polymorphic inheritance via single table inheritance, also known as table per hierarchy, where the data for all the entities in the hierarchy was combined into a single table representing the entire hierarchy. If derived classes have a lot of fields, that STI table starts to look a bit messy. Class table inheritance addresses this by having a separate table for each class in the hierarchy, each table storing only the fields introduced by the corresponding class. This makes the database design tighter at the expense of more complicated queries (because the tables need to be joined at runtime). LightSpeed 3.1 supports class table inheritance both at runtime and in the designer, so you can easily create CTI database schemas from a LightSpeed model.

Other highlights

LightSpeed 3.1 also includes a bunch of smaller features — too many to list here, but here are a few favourites:

• Support for invoking SQLCLR server-side methods via LINQ. This means you can now do SQL Server 2008 spatial queries using LightSpeed!
• Reminder notes in the designer so you can include comments and links on the design surface.
• A T4 directive processor so that you can write your own T4 templates against LightSpeed designer models.
• Lots of improvements to group and join support.

Check out the change log for a full list of enhancements and fixes.

Check it out!

LightSpeed 3.1 is available in the store now, and it’s a free upgrade for existing LightSpeed 3.0 users. Or grab the free Express edition from the Downloads page. LightSpeed 3.1 is a major upgrade: take it for a spin today!

Add your comments
Posted by Ivan Towlson on 24 May 2010