Quino v2.0-beta1: Configuration, services and web

The summary below describes major new features, items of note and breaking changes. The full list of issues is also available for those with access to the Encodo issue tracker.

Highlights

These are the big ones that forced a major-version change.

• Rewrote configuration and application API. (QNO-4666, QNO-4679, QNO-4659, QNO-4772, QNO-4663, QNO-4664, QNO-4360)
• Data-driver architecture has been consolidated. All drivers, ADO, Mongo and Remote, now use the same base implementation, logic and optimization. (QNO-4461, QNO-2913, QNO-4683)
• Rewrote schema migration to return a list of DDL commands (QNO-4732, QNO-4726, QNO-4727) Also improved schema-migration and mapping to database (QNO-4708, QNO-4709, QNO-4605, QNO-4725, QNO-4605, QNO-4728, QNO-4720, QNO-4728)
• Updated the entire security and access-control and authentication API, including adding extensive support for tokens for both ASP.NET MVC and WebAPI. (QNO-4754, QNO-4757, QNO-4747>)
• Renamed IMessageRecorder to IRecorder, IMessageStore to IInMemoryRecorder and consolidated IFilteredMessageRecorder to IRecorder. (QNO-4686, QNO-4696, QNO-4750, QNO-4557)

Some smaller, but important changes:

• Added support for RunInTransaction attribute. Specify the attribute on any IMetaTestFixture to wrap a test or every test in a fixture in a transaction. (QNO-4682)
• Shared connection manager is now disposed when an application is disposed. (QNO-4752)

Breaking changes

Oh yeah. You betcha. This is a major release and we’ve knowingly made a decision not to maintain backwards-compatibility at all costs. Good news, though, the changes to make are relatively straightforward and easy to make if you’ve got a tool like ReSharper that can update using statements automatically.

Namespace changes

As we saw in part I and part II of the guide to using NDepend, Quino 2.0 has unsnarled quite a few dependency issues. A large number of classes and interfaces have been moved out of the Encodo.Tools namespace. Many have been moved to Encodo.Core but others have been scattered into more appropriate and more specific namespaces.

This is one part of the larger changes, easily addressed by using ReSharper to Alt + Enter your way through the compile errors.

Logging changes

Another large change is in renaming IMessageRecorder to IRecorder and IMessageStore to IInMemoryRecorder. Judicious use of search/replace or just a bit of elbow grease will get you through these as well.

Configuration changes

Finally, probably the most far-reaching change is in merging IConfiguration into IApplication. In previous versions of Quino, applications would create a configuration object and pass that to a platform-dependent Quino Run() method. Some configuration was provided by the application and some by the platform-specific method.

The example for Quino 1.13.0 below comes from the JobVortex Winform application.

var configuration = new JobVortexConfiguration
{
  MainSettings = Settings.Default
};

configuration.Add(new JobVortexClientConfigurationPackage());

if (!string.IsNullOrEmpty(Settings.Default.DisplayLanguage))
{
  configuration.DisplayLanguage = new Language(Settings.Default.DisplayLanguage);
}

WinformDxMetaConfigurationTools.Run(
  configuration, 
  app => new MainForm(app)
);

In Quino 2.0, the code above has been rewritten as shown below.

using (IMetaApplication application = new JobVortexApplication())
{
  application.MainSettings = Settings.Default;
  application.UseJobVortexClient();

  if (!string.IsNullOrEmpty(Settings.Default.DisplayLanguage))
  {
    application.DisplayLanguage = new Language(Settings.Default.DisplayLanguage);
  }

  application.Run(app => new MainForm(app));
}

As you can see, instead of creating a configuration, the program creates an application object. Instead of using configuration packages mixed with extension methods named “Integrate”, “Configure” and so on, the new API uses “Use” everywhere. This should be comfortable for people familiar with the OWIN/Katana configuration pattern.

It does, however, mean that the IConfiguration, ICoreConfiguration and IMetaConfiguration don’t exist anymore. Instead, use IApplication, ICoreApplication and IMetaApplication Again, a bit of elbow grease will be needed to get through these compile errors, but there’s little to no risk or need for high-level decisions.

There are a lot of these prepackaged methods to help you create common kinds of applications:

• UseCoreConsole() (a non-Quino application that uses the console)
• UseMetaConsole() (a Quino application that uses the console)
• UseCoreWinformDx() (a non-Quino application that uses Winform)
• UseMetaWinformDx() (a Quino application that uses Winform)
• UseReporting()
• UseRemotingServer()
• Etc.

I think you get the idea. Once we have a final release for Quino 2.0, we’ll write more about how to use this new pattern.

Looking ahead to 2.0 Final

This is still just an internal beta of the 2.0 final version. More changes are on the way, including but not limited to:

• Remove IConfigurationPackage and standardize the configuration API to be named “Use” everywhere (QNO-4771)
• GenericObject improvements (QNO-4761, QNO-4762)
• Change compile location for all projects (QNO-4756)
• Move a lot of properties from ICoreApplication and IMetaApplication to configuration objects in the service locator. Also improve use of and configuration of service locator (QNO-4659)
• More improvements to the recorders and logging (QNO-4688)
• Changes to how ORM objects and metadata are generated. (QNO-4506)
• Separate Encodo and Quino assemblies into multiple, smaller assemblies (QNO-4376)

See you there!