NDO 4.0 Coming Soon -> Q1 2018

We're working hard to get the next version of NDO done. 99% of our tasks are done. There are a lot of changes, some of them breaking existing code. But the switch to NDO 4 will be worth it despite the necessary adjustments of your code.

Prerequisites:

  • Visual Studio 2017 >= 15.7.6
  • .NET Framework >= 4.6.1
  • .NET Standard >= 2.0
  • Your Applications must support .NET Framework 4.5.2 and higher

Query language

NDO finally got a real parser for its query language NDOql. Due to the similarity of NDOql to the WHERE clause in SQL, NDO employed a simple mechanism based on text substitution to accomplish the translation from NDOql to SQL. This simple technology brought considerable limitations. It was nearly impossible to enhance the capabilities of the query language to meet the requirements of daily development work. Now NDOql has a LL1 parser based on an attributed grammar. In fact, we started developing the parser in 2011, but only now we found the time to finish the development.

Breaking Change

We discontinued the development of the old untyped Query class. If you use code like that:

Query q = pm.NewQuery(typeof(Employee), "name={0}");

it won't compile. To fix this, we introduced the interface IQuery:

IQuery q = pm.NewQuery(typeof(Employee), "name={0}");

Behind this interface works an ordinary NDOQuery<T>. This interface exists only for the purpose of porting old code to NDO 4.0.

Linq support

One of the main reasons to change the query engine was the Linq support. NDO 3.0 came with a limited Linq support for simple query situations. However, it was desirable to provide LINQ for all query situations because Linq provides the great advantage of validating the query by the compiler. Now you can write queries like that:

var idValues = new[]{1,2,3,4,5};
var vt = pm.Objects<Employee>().Where(e=>e.Travels[Any.Index].Countries.Oid().In(idValues));

This results in the following SQL query:

SELECT … FROM [Employee] 
INNER JOIN [Travel] ON [Employee].[ID] = [Travel].[IDEmployee]
INNER JOIN [relCountryTravel] ON [Travel].[ID] = [relCountryTravel].[IDTravel]
WHERE [relCountryTravel].[IDCountry] IN (1, 2, 3, 4, 5)

We wrote a lot of unit tests to make the Linq support as powerful as the NDOql language. There should be no more reason to use NDOQuery instead of Linq. But note, that NDOQuery is the base of the query engine. Linq expressions are transformed to NDOql and executed using NDOQuery<T>.

Query Helpers

The NDO enhancer produced nested QueryHelper classes as members of the persistent classes to enable kind of a compiler validation of the identifiers used in a query. Now with Linq, this validation is no longer necessary. If you use QueryHelpers in your old projects, you need to change the query code. We decided to remove the QueryHelpers, because there was no intellisense support for the QueryHelpers in Visual Studio.

.ndoproject…

There has been a big challenge for all NDO developers in the past: maintaining the .ndoproj files. NDO listed all references of a project in this file and the enhancer tried to analyze the referenced DLLs. This led to a lot of trouble. You could disable the analysis with the attribute CheckThisDLL set to false. But every change regarding the relations in a project led to changes in the .ndoproj file which led to conflicts in the source code control.

The solution is simple: We won't list an assembly in the .ndoproj file unless it contains persistent types. New assemblies with persistent types are listed with CheckThisDLL="False". And there will be a user interface in the Visual Studio Extension, that allows to choose, whether an assembly should be analyzed. This will dramatically reduce the number of changes to the .ndoproj file.

The disandvantage of this solution is, that you have to choose an assembly, otherwise you will get an empty NDOMapping.xml file.

NDO providers

Every provider is now in it's own provider DLL. And there are separate DLLs for the database connection UI, which are used by the Visual Studio Extension. If you choose a certain provider, you can load the provider's nuget package with the click on a button. The Sql Server provider is no longer built into NDO. So you have to choose one provider and load it's package in order to start using NDO.

.NET Core / .NET Standard

Microsoft did an excellent job in developing .NET Core. In particular, the .NET Standard is an excellent way to develop for both the .NET Framework and .NET Core. NDO 4 supports .NET Standard 2.0. So you can build a .NET Core project with references to .NET Standard DLLs containing your persistent classes. The NDO DLLs are packaged for .NET 4.5.2 and .NET Standard 2.0. Install-package will fetch the right one for your project.