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. The 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.
Even without the offline version of Astoria, 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.
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.