VistaDB.Net Logo

ADO.NET Data Services with VistaDB for quick client server applications

by Jason Short 3 November 2009

We get questions from users asking how they can build client server solutions using VistaDB, or more often just how they can avoid having to share drive letters to share a database.  My traditional answer in the past has been to build a simple data access layer (DAL) and expose it over SOAP or WCF.  Now with ADO.NET Data Services and our Entity Framework (EF) provider you have another choice.

ADO.NET Data Services (Astoria) 

Not familiar with the codename?  “Project Astoria” was released with .Net 3.5 SP1 under the moniker ADO.NET Data Services.  This  services on the surface appears to be about putting generic objects in front of your data and letting it handle protocols for you.  The fact that you can take any EF model (VistaDB included) and put an ADO.Net Data Service around it in a controlled manner is fantastic.  No more need needing to handle the shared drive scenario.  You connect to a service hub, and that hub then applies all the changes and takes care of the ugly handling of edge cases.  This is similar to a feature that allowed direct from within SQL Server, but I think too many DBA’s didn’t want to expose their actual SQL Server.  Push all that exposure out to IIS and you have the same basic functions.

When is it available?

ADO.NET Data Services is .Net 3.5 SP1 technology and is considered production code.  Today you can easily create a service that runs on one local machine and all clients point to it for their data.  This single server allows all others to make queries against it without concern for direct access to the database.

What if the service is unavailable?

ADO.NET Data Services requires online access to the service.  If the service goes down, the clients can’t do much.  There is an offline version of Astoria in the works from Microsoft to allow a local client proxy to build up and sync to the service endpoint.  I have watched a few PDC demos on it and it looks impressive, but it is still in the Alpha stages at the time of this writing.  I tried to play around with it a little and it was almost all still hard coded to SQL Server and SQL CE.

Even without the offline version of Astoria I think you could build a highly reliable system using just the ADO.NET Data Services.  Your client would have to be intelligent enough to know what to do in a failure to connect scenario, but this is no different than a client server database application today.  The client still has to handle what happens when the server goes away.

Take an intranet site and add a client component

A sample scenario we just recently deployed on the intranet could expand to work over the internet.  We could easily build a client timesheet app (copy local or click once) that knows how to get data through the service rather than direct from the database, and perform the data presentation within that client.

EF Timesheet Model

Sample Scenario

We have an existing website that users use to input their time spent daily, and weekly submit the timesheet.  At the end of time period someone needs to collect the timesheets, approve and pay the correct employees.

ASP.NET Intranet Site

We already have a system that does this all through ASP.Net for the intranet users.  But what if one user needed to work remotely?  We could enable the intranet to be accessed remotely, or we could just expose the service and implement security to prevent unauthorized access.  Using a click once application for the user approving the timesheets would enable her to work in the office or at home when approving and paying the timesheets without her having to know the difference.

Multiple Ways to get at your data

For this particular scenario we decided to leave the intranet alone for the employees.  It works and they know how to use it.  But the person approving the timesheets right now has to come into the office in order to approve them.  She is not very technical and setting up a VPN would be serious overkill for this simple application.

Works with VistaDB today!

Yes, ADO.NET Data Services work with VistaDB 4 today through the EF provider.  We don’t have any samples built specifically around this technology though (hence why this post).

Good sample?

Would this be a sample you would be interested in seeing built?   Would you be interested in seeing how to build and deploy an ADO.NET Data Service using VistaDB?

We have the current Timesheet sample that is a simplified version of our timesheet system.  I thought if we were going to build this local and remote application for our accountant that others might like to see how it is done as well.  I think it makes a very easy scenario to get access to VistaDB database remotely without a lot of custom programming on the developers end.  There is not a lot to know about the communications layer, but it could surely be customized for many deployment scenarios.

Comments

4 November 2009 #

Sean Kearon

The short answer is: yes, please!

Sean Kearon United Kingdom

14 November 2009 #

Chris Bray

Yes, please from me too.

Would this same scenario be appropriate instead of your proposed initial server version, or will that follow shortly, or what?  How does this fit with your future plans?

Chris Bray United Kingdom

15 November 2009 #

js_vistadb

This is not the same thing as a server from us - this is a way to build your own server specific to your needs quite easily.  Building a general purpose one is a LOT harder.  This is specific to your schema and application, you also have to code the permissions, etc.  It works today, nothing special from us.  That is the great part.  You can do it now with no changes from us.

A general purpose SQL Server is a lot harder and has nothing to do with this.

js_vistadb United States

16 November 2009 #

js_vistadb

To clarify my point in the comment above - this scenario is at your application design, has nothing really to do with us.  You can use this pattern / practice to build network client server applications that just so happen to use VistaDB.  The "server" is your service, not ours.  You build and maintain it as a part of your application.

There are lots of ways to build and deploy databases using VistaDB.  The point of this post was that many small business LAN apps do not need a general purpose server.  They need one specific to their application, and that is usually good enough.  This post explains the basics of the pattern.  I will build a sample to show it to you, but I think I am going to have to first explain why the pattern might be useful and where you would deploy it.

js_vistadb United States

Comments are closed

Powered by BlogEngine.NET and VistaDB

Log in