Workflows for Rapid Application Development

A traditional challenge for object-relational mapping is keeping the model in sync with the database schema.  Changes need to be repeated in both places, which increases work, creates the chance of mistakes and breaks your flow as you switch tasks.  LightSpeed supports workflows which avoid duplication and speed up application development.

Driving the Database from the Domain Model

The most convenient way to work with LightSpeed is to do your modelling in the visual designer, creating entities and associations using the toolbox, adding properties using the Ins key or context menu, and configuring properties using the property grid.  You can then use the Update Database command to synchronise the database schema to the model.

This makes for a very rapid development workflow because you are working entirely within one tool, the LightSpeed designer, and synchronising to the relational world requires just a couple of mouse clicks and is normally very quick.

This ‘model first’ approach does not provide fine control over the database design.  You may occasionally find that you need to go into your database tool to tweak column definitions or to set up additional options such as indexes.  At the very least, you will want to review the generated schema before putting it into production.  Nevertheless, this approach makes for extremely efficient rapid application development and allows you to get your model working with a real database with the minimum of extra steps.

Modelling Using Your Database Tools

An alternative approach is to focus first on the database schema.  You can build the database using such tools as SQL Server Management Studio or MySQL Workbench, then drag the tables from the Visual Studio Server Explorer into the LightSpeed model to create entity classes.  You can also use the Update From Source command to synchronise existing entities to the underlying database tables, for example if you have added a column to a table.

The ‘database first’ approach is familiar from older designers such as LINQ to SQL and the ADO.NET DataSet designer.  LightSpeed offers a more rapid development experience because it allows you to update existing entities in a non-destructive way – that is, LightSpeed preserves any additional options you’ve applied to the entities, rather than requiring you to delete and recreate them.  It is particularly efficient if you need to be very specific about the schema of your database – for example, if you have a lot of columns where you need to control the numeric precision and scale.

The disadvantage is that it requires you to swap between the database design tool and the LightSpeed domain model.  This can disrupt your mental flow, especially if you need to add a lot of LightSpeed-side options such as validation – by the time you have finished creating a large table and are ready to flip back to LightSpeed, the details of the columns at the top of the table will no longer be at the front of your mind.  Still, many users feel more comfortable with a database-centric workflow, and of course it is pretty much mandatory if you are working with a legacy database that may be maintained by another team in the organisation.

Which Should I Choose?

You don’t have to!  LightSpeed doesn’t require you to choose a ‘database first’ or a ‘model first’ workflow and stick with it.  You can use whichever option is most convenient at any given time.

Some developers like to drag the first few tables on ‘database first’ style, because this makes it easier to hook LightSpeed up with the right data provider and connection string, then evolve the rest of the model in a ‘model first’ style.

As another example, you might also find that you create most of your entities ‘model first’ but occasionally jump over to the database to design a table that requires particular fine tuning, and bring that table in ‘database first.’  And perhaps while you are working on that table you realise you need to make some changes to other tables; and since you are in the database tool, it’s easier to stay in the database tool to make those changes, rather than jumping back to LightSpeed and breaking your flow.

LightSpeed doesn’t insist that you follow a single regimented workflow.  You can use whichever tool is more convenient at any given moment, and sync across quickly and painlessly.

Reorganising Model Elements in a Database First Workflow

The relational database model doesn’t have a way to express some of the richer concepts of an object‑oriented domain model.  When you drag a table into a model, LightSpeed maps it into the object world, but you may need to fix up the results to fit your desired semantics.  LightSpeed provides a number of commands to help with this.

Convert between one-to-many and one-to-one associations. When importing from a database LightSpeed always infers a foreign key as indicating a one-to-many association. To convert it to a one-to-one association, right-click the association arrow and choose Convert to One-to-One Association. You can convert in the other direction by right-clicking a one-to-one association arrow and choosing Convert to One-to-Many Association.

Move a property between a base and derived class. When mapping a table to a single table inheritance hierarchy, the designer defaults to importing columns into the base class (the one associated with the table). If a property applies only in a derived class, you can move it by right-clicking the property and choosing Move to Derived Class. (LightSpeed allows you to move the property into several derived classes if required.) Conversely, if you decide a derived class property is actually more widely applicable, you can right-click it and choose Move To Base Class. Moving properties preserves attributes such as validation and column mapping so this is safer than recreating the property by hand as well as quicker.

Extract a set of properties into a value object. By default the designer maps all columns directly into properties of the entity class. If you want to model a particular set of columns as a value object, select them, right-click and choose Extract to Value Object. Depending on what other value objects exist in the model you may be offered the choice of creating a new value object type, mapping the columns to an existing value object type or moving the selected column(s) into an existing value object property of the entity.  See Value Objects in the Domain Modelling Techniques chapter for more information.

Hide simple through entities. LightSpeed represents many-to-many associations as through associations, which are mediated by a “through entity.” In most cases the through entity has no attributes other than its associations to the entities with the many-to-many association. In this case you can suppress the through entity in the designer by right-clicking the through association and choosing Convert to Auto Through Entity. If you find you need to add properties or attributes to the through entity, you can reverse this by choosing Convert to Explicit Through Entity.  See Many-to-Many Associations below for more information about modelling many-to-many associations.

Configuring Database Synchronisation

For some databases, LightSpeed offers configurable round‑tripping policies to control database‑specific aspects of synchronisation.  To see whether there are any configuration options for your database, see the chapter Working with Database Providers.  At the time of writing, the only database with a configurable policy is MySQL.

To specify a round‑tripping policy, open the LightSpeed Model Explorer, right-click the root model node, and choose Add New [Database] Roundtripping Policy.