I like to write blog posts where I offer some pragmatic advice. In most posts I try to include tons of code samples and example projects...but this post is different. I am trying to get my head around something so I want to share what is in my head so I can get a conversation started with my readers to help me out. Once you read this post, please comment...
I've finally had a chance to update my Silverlight 2-ADO.NET Data Services example. In this new sample I show how to create a Line-of-Business application (an XBox Game editor) using ADO.NET Data Services against both an Entity Framework model and NHibernate. Unlike earlier examples, this one includes implementation against the ADO.NET Data Service Silverlight 2 library to support saving of changed entities. In addition, I show some techniques for paging, retrieving simple types over an ADO.NET Data Service and full styling of the application. I hope to add support for Forms Authentication in the coming weeks.
It seems that because of some internal NHibernate changes that are required to make NHibernate LINQ work really well, the current version of NHibernate LINQ will not be supported. Evidently there are a number of complex queries that do not work correctly under the current codebase. Its been announced that these changes will be made in the NHibernate 2.1 (which is in development). Follow the link to read the full details!
Data is a funny business. While at the moment I am spending a lot of time teaching Silverlight, my passion still lives in the data. I was brought up on Minisystems (Multi-user CP/M and the like) where you were dealing with something like a database (though we didn't have that as firm a concept as you might think). Later I did quite a lot of desktop database development starting with dBase II (yes, I am that old), Paradox, Clipper, FoxPro and even Access. That naturally led to client-server and N-Tier development. Throughout all the time its become exceptionally clear how much data matters to most applications.
But using databases can be difficult as there is an impedance mismatch with object-oriented development and the natural structure of data. The solution to this for many organizations has been to build data access and business object layers around the data. These layers were meant to simplify data access for most developers and embed the business logic directly into a re-usable set of code instead of it ending up in the UI layer. This was a good thing...
Next Monday night (July 28th, 2008), i'll be giving the short Q&A session at the Atlanta .NET Users Group. The topic? NHibernate's LINQ and ADO.NET Data Services support. If you're interested in using NHibernate but don't want to give up your LINQ skills, stop by for a listen!
Now that my ADO.NET Data Services support has been merged into the trunk of NHibernate.LINQ, I do have some caveats about using NHibernate.LINQ with ADO.NET Data Services. ADO.NET Data Services is a beta 1 product so there are some bugs and issues that you will either need to avoid or work around.
UPDATE: Looks like I uncovered a ADO.NET Data Services bug in FF3. The examples will only work with IE and Safari at the moment.
After spending time creating my own caches of reflection data I found the NHibernate type information to be more complete and faster. Go figure. At this point I am using the SessionFactory's GetClassMetadata and GetCollectionMetadata to return IClassMetadata and ICollectionMetadata interfaces. So far this has given me every piece of runtime information I need and means that I don't need to do any nasty (and potentially fragile) walking through the property interface of the context object. Whew...
I have been diving pretty deep into ADO.NET Data Services (see an upcoming article about ADO.NET Data Services and Silverlight 2 coming soon). I've been looking at the story around non-Entity Framework models through a Data Service and thought that NHibernate through a Data Service would be a great example.
So I tried to get it to work with the NHibernate LINQ project. The example model that the project uses is a simple Northwind model. I thought I'd just take that model and expose it via ADO.NET Data Services. I crufted up a simple Data Context object for ADO.NET Data Model but it didn't work. ADO.NET Data Services was complaining about the fact that the end-points (e.g. IQueryable<Customer>) was pointing at an Entity. This was a bug...a but in ADO.NET Data Services. I hacked together a fix to get around it (and reporting it). If you're interest, the problem is that if the key of the entity is in a base class and *not* named "ID", it fails to find it. Again, this is a bug not a feature of ADO.NET Data Services.
|Vue.js by Example|
|Bootstrap 4 by Example|
|Intro to Font Awesome 5 (Free Course)|
|Designing RESTful Web APIs (new)|
|Building an API with ASP.NET Web API|
|Building an API with ASP.NET Core|
|Building a Web App with ASP.NET Core, MVC6, EF Core, Bootstrap and Angular|
|Less: Getting Started|
|Application Name||WilderBlog||Environment Name||Development|
|Application Ver||v4.0.30319||Runtime Framework||x86|
|App Path||D:\home\site\wwwroot\||Runtime Version||.NET Core 3.0.0|
|Operating System||Microsoft Windows 10.0.14393||Runtime Arch||X86|