I have windows forms app and server side services based on ADO.NET dataservice.
Is it a bad practice to create and initialize one static dataservice client in windows app and use it across the program? For example i can use it in all opened forms(which have bindings to service's datacontext's objects) to call SaveChanges() and not loose tracking.. Or creating a service client instance for every new form is better(because i think after some time with one static client there will be huge memory growth)? But when i create a new client for every form, i assume i create a new connection to the service every time..
May be im wrong and a bit confused about using services in client application. Please help me to understand the right way it works.
Actually the DataServiceContext class doesn't create a connection to the service. The OData protocol it uses is based on REST and as such it's stateless. So creation of the context alone doesn't even touch the service. Each operation (query, save changes) issues a separate and standalone request to the service. From the point of view of the service it's just number of unrelated requests.
As noted above it's usually a good idea to have a separate context for each "section" of your application. What is that exactly depends on your app. If you are not going to load/track huge number of entities (1000s at least) then one context might be fine. On the other hand several contexts give you the ability to "cancel" the update operations by simply droping the context and not calling SaveChanges, which might be handy in some applications.
I would say: It depends. ;) Well your problem is familiar to the decison you have to make, when using directly Entity Framework. So I recommend you to search for such articles and extract their point.
My own experience with EF tells me, that an application with several workflows should have a context for every workflow. Especially, when more than one workflow can be started at the same time and the user can switch between them.
If the application is simple it's proper approach to use only one context.
Related
Working on a WPF application using MVVM and powered by Entity Framework. We were very keen to allow users to multi-window this app, for usability purposes. However, that has the potential to cause problems with EF. If we stick to the usual advice of creating one copy of the Repository per ViewModel and someone opens multiple windows of the same ViewModel, it could cause "multiple instances of IEntityChangeTracker" errors.
Rather than go with a Singleton, which has its own problems, we solved this by putting a Refresh method on the repository that gets a fresh data context. Then we do things like this all over the shop:
using (IRepository r = Rep.Refresh())
{
r.Update(CurrentCampaign);
r.SaveChanges();
}
Which is mostly fine. However, it causes problems with maintaining state. If the context is refreshed while a user is working with an object, their changes will be lost.
I can see two ways round this, both of which have their own drawbacks.
We call SaveChanges constantly. This has the potential to slow down the application with constant database calls. Plus there are occasions when we don't want to store incomplete objects.
We copy EF objects into memory when loaded, have the user work with those, and then add a "Save" button which copies all the objects back to the EF object and saves. We could do this with an automapper, but is still seems unnecessary faff.
Is there another way?
I believe having the repository for accessing entity framework as a singleton may not always be wrong.
If you have a scenario were you have a client side repository, i.e. a repository which is part of the executable of the client application, i.e. is used by one client, then a singleton might be ok. Of course I would not use a singleton on the server side.
I asked Brian Noyes (Microsoft MVP) a similar question on a "MVVM" course on the pluralsight website.
I asked: "What is the correct way to dispose of client services which are used in the view model?"
And in his response he wrote: "...most of my client services are Singletons anyway and live for the life of the app."
In addition having a singleton does not prevent you from writing unit tests, as long as you have an interface for the singleton.
And if you use a dependency injection framework (see Marks comment), which is a good idea for itself, changing to singleton instantiation is just a matter of performing a small change in the setup of the injection container for the respective class.
Generally the work with EF for an looks like this:
Some Web controller calls for a method that has something like this:
using (var ctx = new EntityContext())
{
...
return something;
}
But I guess that in highly loaded application, that has several thousand requests per minute, it might create the problems.
So my question is: maybe it makes sense to manually open connection and keep it alive?
If yes, can anybody share the proper piece of code for such the task?
Thanks in advance
No, don't try to keep opened connections alive. It just won't work, see https://stackoverflow.com/a/9416275/870604.
You're building an ASP.Net MVC application, so the pattern to follow to work with Entity Framework is quite simple in this use case: instantiate a new context for each new controller instance (for example using dependency injection). As a new controller instance is created for each user request, you'll have one new fresh EF context for each request, which is highly desirable.
Don't worry about creating a lot of context instances, it won't create a new DB connection each time thanks to connection pooling.
If you want your application to be scalable, your best option is to also use the async pattern if your version of Entity Framework supports it. See http://blogs.msdn.com/b/webdev/archive/2013/09/18/scaffolding-asynchronous-mvc-and-web-api-controllers-for-entity-framework-6.aspx
EDIT:
Have a look to this overview of the unit of work pattern with ASP.Net MVC and EF.
After closing tag of using element, it automatically close the connection. So you don't want to worry about it. But if you really want to open connection manually, try following (I couldn't test it. May be you need to give connection settings).
ctx.Database.Connection.Open();
What is the most effective way to sync two identically structured DataSets using a Web Service?
The design I use at the moment is simple without a Web Service. All data iscached on the Client, and it will only update data from the MySQL database if an update has been done, this is determined by a timestamp.
If possible I want to keep the same simple design, but add a Web Service in the middle, to allow easier access to the database over our limited VPN.
Best Regards, John
That's one heck of a question, but something I'm doing myself too. Easiest way I guess would be to add a "saved version" property. If it really is a simple design then you could just re-write only the DAL code to get things working for a web service. In fact, if the WSDL is done right, you may only need to make very minor adjustments (especially if the DB was previously designed using EF).
You say you want to sync two datasets simultaneously, but the question I guess is why? And which two? Do you have two web services, or are you wanting to sync data to both the local cache and the online web service (MSSQL db?) simultaneously?
I'm currently working on a web service implementation to a combined web/desktop application (ie. access from different sources).
Now there are two questions I can't really find an answer to:
How would I access the database in the right way (static class? singleton? DI?)? I didn't find any information on using a Web Service in a DI container to help with the database access.
What about writing access? Is this the right way to offer a posibility of writing to the database? Of course, the requests would be protected with a userID and a key.
Note: this is NOT wcf, but the normal web service (ie. asmx file extension).
There are many "right" ways of accessing a database from a web service. Personally, I often use ADO.NET inside a static class (or, more accurately, a class with a bunch of static methods) that generally returns a DataTable (wrapped in a DataSet, which can be serialized and thus easily returned from a web service). You could also use an ORM (like NHibernate), although these invariably have a larger overhead than ADO.NET and thus are a potential source of load problems on your server.
There's no particular reason not to allow write access to your database from your web service. If your application design requires that the database be written to (obviously a pretty common requirement) then it's perfectly fine to do so from the web service.
ADO.NET Data service is the next generation of data access layer within applications. I have seen a lot of examples using it directly from a UI layer such as Silverlight or Ajax to get data. This is almost as having a two tiered system, with business layer completely removed. Should DAL be accessed by the Business layer, and not directly from UI?
ADO.NET Data Services is one more tool to be evaluated in order to move data.
.NET RIA Services is another one. Much better I would say.
I see ADO.NET Data Services as a low level services to be used by some
high level framework. I would not let my UI talk directly to it.
The main problem I see with ADO.NET Data Services has more to do with
security than with anything else.
For simple/quick tasks, in a Intranet, and if you are not too pick with your
design, it can be useful. (IMO)
It can be quite handy when you need to quickly expose data from an existing database.
I say handy, but it would not be my first choice as I avoid as much as I can
the "quick and dirty" solutions.
Those solutions are like ghosts, always come back to haunt you.
ADO.NET Data service is the next generation of data access layer within applications
I have no idea where you got that from! Perhaps you're confusing ADO.NET Data Services with ADO.NET Entity Framework?
One shouldn't assume that everything Microsoft produces is of value to every developer. In my opinion, ADO.NET Data Services is a quick way to create CRUD services, which maybe have a few other operations defined on the entity, but the operations are all stored procedures. If all you need is a database-oriented service, then this may be what you want. Certainly, there's relatively little reason to do any coding for a service like this, except in the database.
But that doesn't mean that ADO.NET Data Services "has a place in the overall design" of every project. It's something that fills a need of enough customers that Microsoft thought it worthwhile to spend money developing and maintaining it.
For that matter, they also thought ASP.NET MVC was a good idea...
:-)
In my opinion other answers underestimate importance of ADO.Net Data Services. Though using it directly in your application brings some similarity to two tiered system , other Microsoft products such as .Net RIA Services , Windows Asure Storage Services based on it. On the contrary to the phrase in one of the answers "For simple/quick tasks, in a Intranet, and if you are not too pick with your design, it can be useful" it may be useful for public websites including websites in ASP.Net MVC.
Dino Esposito describes the driving force for Ado.Net Data Services in his blog
http://weblogs.asp.net/despos/archive/2008/04/21/the-quot-driving-force-quot-pattern-part-1-of-n.aspx
"ADO.NET Data Services (aka, Astoria)
Driving force: the need of building richly interactive Web systems.
What's that in abstract: New set of tools for building a middle-tier or, better yet, the service layer on top of a middle-tier in any sort of application, including enterprise class applications.
What's that in concrete: provides you with URLs to invoke from hyperlinks to bring data down to the client. Better for scenarios where a client needs a direct|partially filtered access to data. Not ideal for querying data from IE, but ideal for building a new generation of Web controls that breath AJAX. And just that."