Quino v2.0-beta1: Configuration, services and web
Published by marco on
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
toIRecorder
,IMessageStore
toIInMemoryRecorder
and consolidatedIFilteredMessageRecorder
toIRecorder
. (QNO-4686, QNO-4696, QNO-4750, QNO-4557)
Some smaller, but important changes:
- Added support for
RunInTransaction
attribute. Specify the attribute on anyIMetaTestFixture
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
andIMetaApplication
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!