- DataObjects.Net v4.4 - it brings really dramatic changes; most important of them are described in the following part of this post.
- New, dedicated DataObjects.Net web site. We know we should do this much earlier, and now even our own patience is finished ;)
It is almost finished, and will be launched quite soon. Few screenshots:
Hopefully, you'll like it.
As I wrote, we implement a set of dramatic changes there, but mostly they are related to refactoring we planned for pretty long time. Most important changes there include:
- Elimination of most of of assemblies. We'll leave just Xtensive.Core, Xtensive.Aspects, Xtensive.Aspects.Weaver (not necessary to reference it) and Xtensive.Orm, so you should reference just 3 assemblies from your code. It's a result of significant internal refactoring + ILMerge.
- We're starting to use actual assembly version numbers from this release. All assemblies there are marked as v22.214.171.124 (their file versions reflect minor revisions and build numbers). Assembly versions will be changed on each significant API change. Project upgrade tool will help to automatically upgrade your projects to the new version.
- Namespace renaming:
Xtensive.Storage is split into Xtensive.Orm (most of classes you need are there now) + Xtensive.Storage;
Xtensive.Core.* are renamed to Xtensive.* (but Xtensive.Core itself is left as is);
Xtensive.Modelling become Xtensive.Core.Modelling;
Xtensive.Integrity is gone;
there are few other less important changes.
- Usage of Session.Current / Session.Demand() is optional now. This actually means explicit passing of Session is recommended now; old API fully works, but all such methods are marked as obsolete; there are new methods for any part of API that formerly relied on current Session (e.g. there is Session.Query.All<T>()). Automatic session activation on method call is optional now (this behavior is managed by one of SessionOptions flags); DO itself does not require it, but it can be used when it is convenient (e.g. this is still a recommended practice for web applications). We did this because of two issues:
a) We discovered people tend to think DO isn't designed for concurrent operations (such as passing persistent objects to another thread). Of course, this isn't true, but "current Session" concept makes a different impression. There were people stating it as one of blocking issues.
b) People used to different style, and finally we understood it's a bad idea to make them to study our own one.
c) The advantage of this style is really subjective. It hides the complexity, although people used to manage it by their own in this case. Moreover, it doesn't bring any essential advantages to us - i.e. actually, framework does not need this feature to be enough extendable and flexible.
d) This technique isn't friendly to new "async" and "await" in C# 5 (i.e. there shouldn't be async methods in SessionBound descendants), so its usage must be 100% optional.
- SessionOptions brings 3 pre-defined combinations of flags now: ClientProfile, ServerProfile and LegacyProfile. Legacy profile is the mode you use now. Server profile is legacy profile without automatic session activation (since now this is optional). And finally, there is a client profile: each Session operating in this mode is created along with attached DisconnectedState, so it works nearly as DataContext in EF or Session in NH (from many points - even better). This mode allows people using different ORM frameworks to migrate to DO a bit easier.
- Xtensive.Practices is finally separated there. Btw, it will be shipped with full source code.
All above changes are mainly related to API. But certainly, this isn't all:
- We've actualized Manual. Btw, it's split in multiple topics in help, so it's much easier to study it there.
- Samples are now organized by technology. Also, they don't require IIS and installation of "IIS Metabase and IIS 6 configuration compatibility" components for Windows to be executed from VS.NET. Sandbox projects are moved to samples. Finally, there is a good Readme.htm that fully explains how to create a sample database, compile and and run them.
- We'll ship a set of .RAR archives allowing to download only necessary part of each build (e.g. just binaries). Actually, we already are.
All these changes (along with the dedicated web site) must make the product much more user-friendly - especially, for its adopters.
v4.4 will be released during November.
We're pushing the development of DataObjects.Net in two directions:
- Adding new and unique features and APIs. That's what distinguishes us from others. Frankly speaking, we've paused our activity here for a certain period, so our near-time goal is to push this part forward.
- Adding old and widely adopted features / APIs. That's what makes DO easier to study and more compatible with others. We must propose an alternative to nearly any nice feature available in competing products.
As you see, initial release of v4.4 is mostly focused on initial user experience and compatibility / similarity with competitors, but its subsequent updates (v4.4.X) will be devoted mainly to extensions.
Our further (pretty near) plans include: