Posts Tagged ‘data services’
I am in the process of deploying my first project using Ado.net Data Services using an Entity Framework Context and I thought I would share some of my experience.
Data services comes with the ability to apply credentials on the context, but if you’re wanting to roll-your-own method of passing credentials (such as a cookie) you’re not out of luck. The client ObjectContext supports a “SendingRequest” that is fired every time an HttpWebRequest object is created. In the args object you can get access to the web request. The code looks something like this:
You can then use the cookie you in the service by overriding the “OnStartProcessingRequest” method.
2) .SVC mapping in IIS
For the .svc mime type mapping in IIS you’ll need to make sure the “POST”, “PUT’” and “DELETE” methods are supported.
3) Object Context and connection string
After having trouble creating an object context using an .edmx file directly in an asp.net web site I moved it do a class library and everything seems fine now. Also, it’s very important to make sure your connection string is formatted correctly. When you create and ObjectContext using .edmx it will create a connection string in the .config file that corresponds to the class name of the object context. Additionally, it is very important the connection string “metadata” section be formatted as “metadata=res://*/Context.csdl|res://*/Context.ssdl|res://*/Context.msl;”. And this is where it gets to be interesting. When you create the .edmx file a custom Object Context is created, but also portions of the .edmx file are embedded as resources in the compiled assembly. The “res://*/” paths, which are pipe separated (“|”), need to correspond to these resource names in the compiled assembly. If you don’t don’t know the names you can always use RedGate Reflector to find them. Thanks to Danny Simmons at Microsoft for pointing the right me in the right direction.
4) Turn on debugging output if needed.
There are two things you can do to get at error messages in the service output if necessary.
- Apply the ServiceBehavior attribute to the service. When you do this you want to include (“IncludeExceptionDetailInFaults = true”).
- In the “InitalizeService” method include “config.UseVerboseErrors = true”.
This will allow you to get at the exception details. Make sure you turn off when in production.
Okay – corny title. Sorry. But after my initial elation in working with Ado.net Data Services I ran into a couple of “issue” and this news helps keep me going. Such as not being able to get a virtual count being the most outstanding problem. Here’s that link: http://blogs.msdn.com/astoriateam/.
Looks like it will be a side-by-side release. Now that could be good or very good. Hint – if we have to give up the VS 2008 tooling it’s only “good”.
I’m very pleased that they are responding sooner that forcing a longer wait until .Net 4/VS 2010. I still very much dislike the Entity Framework v1 design choices (specifically the forced reliance on an xml mapping schema), but the pain is worth the gain. The book “Programming Entity Framework” is a big help.
Sorry, I have been away for a while. Been sick and busy, a frustrating combination. But … I digress. I have started to use Ado.net Entity Framework/Data Services on a project I am working on. So far it has been a very mixed experience.
Thus far I have really enjoyed working with the EDM in general and with the Data Services managing data thru n-tier is actually. Seriously easy. All you need to do is create a database, map it with a .edmx file, wire it up to an ado.net data service, create a client of some kind away you go. At a modest pace you can do that in about 15 minutes. Of course, this is the most simple scenario and would fit the security concerns of a deployment scenario. The end result is an experience that is vastly superior to using DataSets or trying to move objects between tiers, mainly because of LINQ.
What is been the largest pain point has been .edmx and the designer, especially in light of what the Ado.Net team demoed at the 2008 PDC. The Entity Framework Futures session demonstrated coming functionality (hopefully) that would all one to map POCO objects straight to an ObjectContext sans xml mapping file (.edmx) using attributes. This would be so much easier than having to use .edmx and its verbose mapping scheme. How enjoyable the experience would be if you could just declare an ObjectQuery property in a custom ObjectContext and use attributes for table and association mapping. It wouldn’t be as fancy, but it should would be direct and I think less cumbersome than current requirement of an .edmx mapping file. I understand the necessity of .edmx in certain situations, but I wonder how much time the team could have saved if they would punted an XML representation down the road .Net 4.0. They could have had much more time to develop a good designer and perhaps used XAML 2009 for their representation. Working with the designer is tragic and reminds me of designing typed datasets in .net 1.0 Right now I find I often have to close/open a solution because sometimes the designer refuses to open, and then when working in the Designer the experience is buggy or incomplete. For example, when you set an association between entities the designer doesn’t clean up and leaves you to deal with a cryptic error. That’s just one example, there are more.
So what’s the conclusion? I wouldn’t go back to dataset or rolling my own object because the combination of Ado.net Entity Framework/Data Services brings too much to the table. I would rather work around the current short comings as they prepare for their next release because this combination of tech going forward brings too much value and ultimately save too much time to be ignored. But right now I would say this is clearly a leading edge and requires a good amount of “homework” to get right. Venture at your own risk, but so far I think it’s worth it.