NDO 4.0 is out

 

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

Note: .NET Standard dlls in versions > 2.0 can't be used with NDO, because the NDO assembly enhancer is a .NET Framework application and must be able to load the assemblies, it analyzes. .NET Standard 2.1 assemblies can only be loaded in .NETCore apps >= v. 3.

Test NDO 4.0 Today

Just install the ndo.dll package from Nuget. The ndo providers are also available at Nuget. The names of the providers are ndo.sqlserver, ndo.mysql, etc.

Query language

NDO now has 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 recently 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. We recommend changing the code to use Linq.

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 core 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…

In the past, there has been a big challenge for all NDO developers: 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 project references 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.

This improvement has it's price: You have to choose at least one assembly in the UI, otherwise you get an empty NDOMapping.xml file.

And since we are at NDOMapping.xml: If you delete the name NDOMapping.xml in the configuration dialog, NDO creates a mapping file that includes the project name:

<ProjectName>.ndomapping.xml

NDO finds files with this name as well as the NDOMapping.xml.

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, .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. Nuget will fetch the right one for your project.

Dependency Injection

NDO uses a simple DI container implementation for internal purposes. You can register your own classes and interfaces to the DI container at any time. You can register classes and instances at a static level where registrations are available throughout the application's lifetime. And you can register classes and instances with a container that is only available during the lifetime of the PersistenceManager. NDO automatically resolves the dependencies of your persistent classes when you create them.

The DI implementation is modeled after the Unity containers, since Unity was first used as container implementation. But Unity showed some strange behavior, so we decided to simplify things with an own implementation, which is a subset of Unity.