I want to develop a simple Windows Forms application in C# using WPF and MVVM that will connect to an SQL server installed on a different machine. So I've read that, even for a simple structure like that, some developers would use WCF and make their application Service Oriented. I totally understand that SOA is the way to go with WebApps and SilverLight, but I don't see why, for a simple situation like a Winform and an SQL Server, would somebody use WCF. I would really appreciate if somebody could give me a couple of good reasons why to use WCF in my WinForm application (considering that the SQL Server will be in the same network with the clients)?
Thanks,
Aris
If you don't need it, don't use it :)
But you should consider whether there are plans to change the application - for example, to convert it to a web app or Silverlight. In that case, having a service which does the database access will make the conversion easier. Personally, I think this is usually over engineering, but it may make sense for your application if you foresee one such change in the near future.
Do you have to use WCF? Nope.
In my opinion, though, there aren't too many reasons NOT to create a WCF service for this sort of work.
Using WCF services for your different layers instead of class libraries is an excellent way to go. Using WCF, you can control how your components are hosted (IIS and http all the way down to in-process with named pipes) and where they're located.
WCF doesn't add much overhead and in return you get a bunch of benefits.
The point isn't necessarily to worry about SOA, but more to think ahead about flexibility and better reuse.
I can't think of a particularly compelling reason, other than habit. When you do something the same way for 99% of your projects, it's often just as easy to do it the same way for the other 1% if it doesn't go actively against your requirements.
The only other reason I can think of would be if you're writing something that could, potentially, be really useful externally or as a web-app. Using WCF in that instance would allow any client which could connect to the host (web browser, external application, or whatever) to connect to your library without you having to modify things after the fact.
If you know for (relatively) certain that this will only be a windows application run on the desktop of your own organizations' employees, I don't see a reason to use WCF in this instance.
Bottom line is that you're on a network so WCF or any web service makes sense.
Your network calls are all going to be async (or should be!). That's easy to do with WCF. Not so much with direct connections.
Even WinForm applications are connected these days.
I personally don't believe in creating services for everything, just to be creating services. Create a service when you know that you have a consumer for that service. Don't just say, "well, we might use it from another application some day", and call that an excuse for a service.
Services should be planned. The service contracts should be those which are required by their consumers. No consumers, no contracts, so no service.
Related
does someone know if it possible to use one WCF Data Service as data source of another WCF Data Service? If so, how?
So the short answer is yes. Actually I have consumed one WCF service in another (HttpBinding coming to a service on computer, then that service had a NamedPipesBinding service to communicate with multiple desktop apps, but it did some data transformation in the middle). That would not be an issue at all, you would set up a proxy/client just like you would in a desktop client, and handle everything in your new service as if it was just passing information along, you could even create a shared library for the DataContracts and such.
HOWEVER I would not suggest the leapfrog method in your implementation. Depending on how many customers you are potentially opening the door too, you may be introducing a bottlekneck, if you have a singleton service, or overload your existing service in the case of many connections from the new one. Since you have a SQL server, why would you not have a WCF service on your web/app server (public) that connected to it and provided the data you need? I'm only thinking this because your situation can become exponentially complicated when you start trying to pass credentials for authentication and authorization between the two, depending on your security settings. Another thing to consider is the complexity in debugging this new service and the old one, and a client at the same time, as if it wasn't a pain just to do server and client, since you are opening it to a public facing port, there are different things to set up, and debugging everything on the same machine is not the same as a public facing application server.
Sorry if this goes against what you were hoping to hear. I'm just saying that it is possible, but not suggested (at least by me) in your particular case.
This is a design question, I guess there going to be several suggestions (I hope so!)
We are a small travelling agent office, we are developing a software for our need. We have 30 clients on the local LAN, sometime later some other 5-10 from outside the office. (This will be agents on route).
Would you create a WCF service for this scenario or just leave the DL in the client (for direct access to the SQL)??
Our DataAccess Technology is EntityFramework 4.0 (4.1), ALL clients are Windows 7 based.
About the travelling agents, wouldn't it be much more simple to just use a VPN for the agents connection??
We have plans to supply our guides (outside the office ) with 3G tablets in about 1 year from now.
Developing clients with a DL is of course much more straight forward solution, but our plans for the near future will require some kind of service. The tablets application will have a much more simple interface and functionality. So maybe developing a WCF service dedicated for the tablets will be better?
Our first consideration is time, we are in great need for a working software.
Well, I hope I managed to share with you our thoughts clearly enough.
Thank you for reading.
I think one technology that would be a) very well-suited to your needs, and b) doesn't impose a huge overhead on your development effort would be WCF Data Services.
This is a REST-based WCF service based on a model - like your Entity Framework model.
Check out:
the WCF Data Services Developer Center
MSDN docs on WCF Data Services
I would see clear benefits in architecting a new solution from the get-go to use a service-based approach - even if your local LAN client might end up not using that service layer. Thinking in services, thinking also about the limitations of sending data across a potentially slower link than your LAN usually helps avoid silly mistakes like loading 200'000 customers into a dropdown box and stuff like that...
Having a service layer also makes your client app much less dependent on the actual database technology - that client might be a Winforms, WPF or Silverlight app, a web site, a tablet - you name it. If they all share the service layer, development of the client app will become less of a burden - the majority of your work will be in your data model and your service layer (which is shared across all clients).
I am trying to figure out the best way to approach this design... Here is some background of what I'm trying to do:
I have a simple digital I/O controller that sends data to my computer via Ethernet. I have a program that can receive this data over Ethernet. I would like a separate front end application that presents this data in a GUI. I am trying to figure out the best way to interface the program that grabs the I/O data over Ethernet, and the program that displays this as the front end. This interface should run whenever the computer boots and constantly poll the I/O in the background.
I've read about Windows Communication Foundation (WCF) and this seems like a nice way to do this. As the windows service would quietly keep polling the I/O and any clients that attach to the WCF interface can present this data in a GUI.
Am I going about this all wrong? Does this seem like a good way to do things? How will my front end clients grab the data from the WCF service?
Thank you in advance.
That's precisely the way I have done it - hosting a WCF service in a Windows service. The Windows service is the process; the WCF service is where the work is done.
In my case, my WCF-based CollectionService is on standby most of the time. I use WCF to start and stop the collector because the WCF programming model makes this easy. However, to get the data from the collector to the UI, I use a TCP socket, not WCF. I know that WCF has a streaming mode, but (1) I've never used it and (2) I believe there is some amount of overhead using WCF this way. The socket is simply a comfortable fallback for me, but I think WCF could be made to work.
If you're just starting, you can refer to these two answers for getting your Windows service up and running using C#. From there, you'll just need to create the ServiceHost and close it in the OnStart() and OnStop() callbacks of your Windows service, respectively.
Easiest language for creating a
Windows service
How to make a
.NET Windows Service start right
after the installation?
If you are new to WCF, take a look at this SO question.
Good and easy books/tutorials to learn WCF latest stuff
One more thing. In the course of your work on this, you may find that you want the WCF service to provide events to your UI when certain things occur. For example, you might provide an event that periodically notifies the UI of the number of bytes that have been received. For this, I would strongly recommend this article by Juval Lowy, one of the WCF gods.
What You Need To Know About One-Way Calls, Callbacks, And Events
His Publish-Subscribe Framework is available for free at his website, IDesign.net, along with several other working WCF examples.
Hope this helps.
I have a DAL that is replicated across multiple apps (I know its a bad design but ignore this for now) , what I want to do is this...
Create a WCF DAL Component that will be accessed via all Desktop apps.. Could anyone share their thoughts on following ??
I am intending to use TCP Binding
What will be the overhead in terms of performance ( since 1 DAL component will b consumed via multiple apps )???
Since TCP Binding can only be hosted on IIS-7.0, this will be another overhead in terms of hardware+s/w ( or is it possible to have HTTP binding at top and TCP beneath that so that I can use IIS version 5 or 6 )???
Can I have multiple end points for multiple apps and is good from performace point of view as it will help us creating different thread for different client apps and can have diff contracts in future as well so that one application goes unaffected due changes in the DAL..
What Instancing Mode is preferred in this case (we are expecting a traffic of 100 concurrent user per day) , and DAL already handles this using SINGLETON design pattern.
Let me know your thoughts on all of above mentioned points and also if you could provide me more insight on this... will b gr8.
Thanks in advance...
Let me answer a few:
1) netTcpBinding is a great binding - very fast, very good in performance - definitely go with that!
3) Either host in IIS 7.0, or then self-host - write a little Windows NT Service and handle the hosting yourself. Gives you more control, and the ability to manually start and stop your DAL Service. I wouldn't even bother trying to get NetTcp working on IIS5/6 with some kind of a trick/hack - waste of time.
4) Multiple endpoints of the same binding are neither useful, nor do they help with performance.
5) I would always use "Per-Call". Each service request gets its own instance of the service, the call is handled, and then you're done. That makes programming the WCF service implementation a snap - if you go singleton, to have any performance at all, you need to worry about multi-threaded and thread-safe programming - a mess, really. Don't do it. NO, just don't do it.
A DAL should always be stateless and should operate on the "open the database connection as late as possible, do the work, and close the connection as soon as possible" again pattern which is a perfect fit for the per-call instance mode. When your service request comes in, the connection is opened (those are pooled in a connection pool in ADO.NET anyway, on the server side), the works is done, and the connection is closed again.
I am to design a webservice using WCF that yields methods that don't require a session (like static calls, eg: giving back some information about the webservice itsself) and other methods that require a session.
furthermore, the session based methods are using Workflows that are supposed to be able to be changed at runtime.
my current design would look like this:
there is a singleton service that runs in IIS that handles all the per call methods which also works as a host for the session based services. that way the singleton class knows about all the sessions and can halt the running workflows to exchange them.
is this a good/possible design choice?
is this a common scenario that uses a common design?
would be happy about any reading hints as the msdn help wasn't such a help to me.
thanks for your answers
-redoced
Using a singleton WCF service class is almost never a good idea - unless you really have just one single (physical) resource which you want to protect from concurrent access, it doesn't really make sense.
Because: either it's not multi-threading capable, but in this case, it becomes a huge bottleneck - requests are handled strictly sequentially - one after another. Not very good for performance.
Or then you need to make the whole service multi-threading aware - and let me tell you, making this properly, safely, and efficiently isn't for the faint of heart. It's really really hard to get this right, and make it perform well.
I really don't see any need for this, at all.
leave you "static" message calls (as you call them) be per-call services - those are easy to program, work well, perform well, never cause any multithreading issues
those few service calls (hopefully!) that do require a session - put them on their own service endpoint(s), make them per-session, use the "SessionId" in your session to identify them. It's a bit more work than per-call - but still nowhere near as complicated and error-prone as multi-threaded programming
Resources for WCF sessions:
MSDN article on Using Sessions in WCF
WCF Sessions blog post
Resources for WCF durable services (that persist their state between calls):
Blog post on "durable services"
WCF Durable Services
Orcas durable services
Screencast by Mike Taulty on durable WCF Services
Resources for WCF Workflow Services:
Foundataions: Workflow Services
Channel9 webcast: Intro to Workflow Services
Webcast: Intro to workflow services in WCF 4.0