By the time this blogpost will be published, the Winter 2013 release of Data Abstract will already become available. I feel that I should talk about several important features made available in it, and about a few things that will soon fade in oblivion.

So the new features first.

Private Schema tables access. Local Data Adapters (both dataset-based and DA LINQ ones) are now allowed to access Schema tables that aren’t marked as ‘public’ and thus aren’t accessible by remote clients. There is no need anymore to write additional code to access these tables using local data adapters or from Schema scripts.

Data Abstract for Portable Class Library (aka DA/PCL). Yes, this release contains a (limited) port of Data Abstract to Portable Class Library. You can now build one Class Library and then reuse it in Silverlight, Windows Phone or Windows Store application.

Unfortunately the dreaded Technical Debt monster arose and strikes from the back so the PCL library has some limitations on the desktop .NET Framework. The problem is that the RemoteLinqDataAdapter class is located in differently named assemblies in desktop .NET and in all other platforms (namely RemObjects.DataAbstract.Linq.dll and RemObjects.DataAbstract.dll). Introducing the .Linq assembly back-when was a good (and the only) way to introduce DA LINQ without breaking support of .NET 2.0. And an additional assembly wasn’t an issue until a need to create portable set of assemblies arose.

I can say that we plan to provide improve this to more seamlessly support all four .NET platforms (i.e. Windows Phone, Windows Store (WinRT), Silverlight AND desktop .NET) in the next release of Data Abstract. Stay tuned ;)

Important note: Up to this release, non-desktop Data Abstract assemblies had a platform name suffixes in their names (f.e. RemObjects.DataAbstract.Silverlight.dll or RemObjects.DataAbstract.WinRT.dll). Since this release these suffixes exist no more, so ALL assemblies have the same name.

And now to the stuff now considered obsolete.

Data Abstract provides two binary data adapters: BinDataAdapter and Bin2DataAdapter. The former one, BinDataAdapter data adapter, is now considered obsolete and will go away in the next major releases. We have Bin2DataAdapter data adapter that serves the same purpose, is way more advanced and feature-full and, unlike the BinDataAdapter, is supported by Data Abstract on platforms other than .NET and Delphi. The only reason we still shipped BinDataAdapter this long was backwards compatibility. Yet it is time to finally take a step forward and leave this obsolete data adapter behind. So, in the unlikely case that you are still using this data adapter, you really should to consider to switch to the Bin2DataAdapter data adapter. There’s no downside.

Also we have a set of ASP.NET components provided in the RemObjects.DataAbstract.Web.dll. This entire .dll will be removed in the next major release, and has been marked as obsolete. The reason behind this is that the very approach implied by these components is outdated and based on an old model of using ASP.NET. Mixing the UI (ie .aspx code) and data access results in dirty code and errors that can be detected only at runtime, thus resulting in a nightmare while supporting such apps. Believe me, I know. So if you are not using the RemObjects.DataAbstract.Web, then there is no need to worry. If you do then I’d strongly suggest you to either move to the properly layered architecture, where UI has no data access code and/or to take a look at the Data Abstract for JavaScript. It allows to create modern and robust UI and is shipped together with Data Abstract for .NET.

That’s all for now.

Still stay tuned – soon I’ll show you some exciting new features of RemObjects SDK and Data Abstract.