views:

418

answers:

2

Following the KISS principle, I suddenly realised the following:

  • In .NET, you can use the Entity Model Framework to wrap around a database.
  • This model can be exposed as a web service through WCF.
  • This web service would have a very standardized definition.
  • A client application could be created which could consume any such RESTful web service.

I don't want to re-invent the wheel and it wouldn't surprise me if someone has already done this, so my question is simple: Has anyone already created a simple (desktop, not web) client application that can consume a RESTful service that's based on the Entity Framework and which will allow the user to read and write data directly to this service?

Otherwise, I'll just have to "invent" this myself. :-)


Problem is, the database layer and RESTful service is already finished. The RESTful service will only stay in the project during it's development phase, since we can use the database-layer assembly directly from the web applications that are build around it. When the web application is deployed, the RESTful services are just kept out of the deployment.

But the database has a lot of data to manage over nearly 50 tables. When developing against a local database, we can have straight access to the database so I wouldn't need this tool for this. When it's deployed, the web application would be the only way to access the data so I could not use this tool. But we're also having a test phase where the database is stored on another system outside the local domain and this database is not available for developers. Only administrators have direct access to this database, making tests a bit more complex.

However, through the RESTful service, I can still access the data directly. Thus, when some test goes wrong, I can repair the data through this connection or just create a copy of the data for tests on my local system. There's plenty of other functionality and it's even possible to just open the URL to a table service straight in Excel or XMLSpy to see the contents. But when I want to write something back, I have to write special code to do just that. A generic tool that would allow me to access the data and modify it would be easier. Since it's a generic setup around the ADO.NET Data services, this should be reasonable easy too.

Thus, I can do it but hoped someone else has already done something similar. But it appears that there's no such tool made yet...

+5  A: 

You are referring to ADO.Net Data Services. It basically creates an Entity Database Model and adds a REST frontend to the service using ASMX. There is a How To article availble from MSDN here on consuming the service using .Net. I have also done the same thing using the normally WebClient class in .Net in the past.

You can also look at the WCF REST Starter Kit if you want to roll your own based on Entity Framework. The starter kit also contains a handy new WebClient class that can be used to communicate with REST services.

Clarification

There is no prebuilt application client that I am aware off which will talk to these service, since they are pretty much accessing the data using Web Services. There is the Microsoft Smart Client Factory which is most likely the closest thing I have worked with.

I mentioned the above 2 options since they already have libraries in .Net that work with them directly, either as a referenced Web Service, or for the more adventurious, myself included, using the WebClient library or alternatively the new HTTPClient library in the WCF REST Starter kit.

I have used both, in Windows, Web, Silverlight and WCF. The latter being the easiest since they are focussed at REST.

We are currently investigating Prism which strongly leans to using this method when using WCF for front-end development.

Assumption

With regards to this question, you are making a generic assumption that wrapping ADO Entity Framework with a WCF service it will be generic. ADO.Net Data Services is the closest you will get, however the structure of the database will fundamently change the way you interact with it. Going a level higher in a "generic" way would be dangerous, as these 2 technologies, individually or together, are already as generic as possible.

Diago
The client should not have to know anything about the database structure. The dataservices return an atom feed which lists all tables, which could be displayed in a combobox. Pick a table and it would return the data from this table, which could be displayed by a grid, simply by looing at the elements from the "d" namespace. Additional functionality shouldn't be that hard, since the dataservice has generalized most of it already. Dangerous? Yes. But as an internal tool still practical. (The security issues needs to be dealt with in the service, not the application.)
Workshop Alex
As much as your sample is valid, and applied could work, it hardly makes much sense in a business environment. Reality is you will never show all the fields of a table to your end user. Also, it would be very generic. Therefore I stand by my answer. In your **environment** it may be practical, but apart from a project on CodePlex being created, I haven't seen any such client around.
Diago
In a business environment, no. But in a development environment, where you'd want to take quick peeks at the data, such a tool is very practical.
Workshop Alex
Agreed. However in our environment it is called SMSS. Which all the developers have access too :). However I agree with the idea. It is just too much work, and unless you are developing software for your development environment, is going to be more cumbersome then usefull. IMHO.
Diago
+2  A: 

In addition to Data Services (+1), consider RIA Services. It's like a domain-specific version of data services for Silverlight or WPF clients. Less flexible, but easier, than Data Services.

Craig Stuntz
Unfortunately, the Entity model is already done. The RESTful service around it was also easily added and deployed. For now, I'll have to do with the stuff that's deployed and can't do much to adjust the server architecture. (Well, not until the next update.) Testing will take a month, so I have a month to build my own solution if none exist. (Should take me two days, I think.)
Workshop Alex
Both data services and RIA services work with your existing entity model.
Craig Stuntz
+1 I haven't worked with RIA much, although I should get into it. I am to old to keep up.
Diago