Where in this pattern I can "place" services, about which I some much hear and want use? What is the purpose of use Services (WCF) in MVVM ?
Which of services: Web Services, WCF or RIA is the best and the easiest for MVVM? I only read about realy simple WCF contracts and RIA which have from start create Update,Insert etc method...
Model-View-ViewModel is a UI separation pattern. It does not specifically address the role of services in your application. But in general, your "Model" will likely have persistence needs that will need to cross out of the UI layer into a service layer and WCF provides a good transport for that.
Using a dependency injection framework (which is common in MVVM) you can register your WCF service interfaces with the container so that you can work with interfaces instead of directly with the WCF client proxies.
With regard to WCF data services vs. RIA services, I don't know the jury is still out on that. WCF data services is released, RIA services is not. RIA does tend to blur the lines between what is client and what is server. This can be both good and bad. It solves a lot of problems with duplicated validation rules and such but I personally get a little nervous about such tight coupling of the client and server.
Related
I am totally confused between WCF and ASMX web services. I have used a lot of web services in my earlier stage, and now there is this new thing introduced called WCF. I can still create WCF that function as a web service. I think there will be more stuff in WCF.
What are the differences between WCF and Web services? When should each one be used?
Keith Elder nicely compares ASMX to WCF here. Check it out.
Another comparison of ASMX and WCF can be found here - I don't 100% agree with all the points there, but it might give you an idea.
WCF is basically "ASMX on stereoids" - it can be all that ASMX could - plus a lot more!.
ASMX is:
easy and simple to write and configure
only available in IIS
only callable from HTTP
WCF can be:
hosted in IIS, a Windows Service, a Winforms application, a console app - you have total freedom
used with HTTP (REST and SOAP), TCP/IP, MSMQ and many more protocols
In short: WCF is here to replace ASMX fully.
Check out the WCF Developer Center on MSDN.
Update: link seems to be dead - try this: What Is Windows Communication Foundation?
ASMX Web services can only be invoked by HTTP (traditional webservice with .asmx). While WCF Service or a WCF component can be invoked by any protocol (like http, tcp etc.) and any transport type.
Second, ASMX web services are not flexible. However, WCF Services are flexible. If you make a new version of the service then you need to just expose a new end. Therefore, services are agile and which is a very practical approach looking at the current business trends.
We develop WCF as contracts, interface, operations, and data contracts. As the developer we are more focused on the business logic services and need not worry about channel stack. WCF is a unified programming API for any kind of services so we create the service and use configuration information to set up the communication mechanism like HTTP/TCP/MSMQ etc
This is a very old question, but I do not feel that the benefits of ASMX have been fairly portrayed. While not terribly flexible, ASMX web services are very simple to use and understand. While WCF is more flexible, it is also more complex to stand up and configure.
ASMX web services are ready to stand up and add as a webservice reference as soon as you add the file. (assuming your project builds)
For the simple development workflow of
create webservice -> run webservice -> add webservice reference, an ASMX webservice has very little that can go wrong, not much that you can misconfigure, and that is it's strength.
In response to those that assert that WCF replaces ASMX, I would reply that WCF would need to add a streamlined K.I.S.S. configuration mode in order to completely replace ASMX.
Example web.config for an ASMX webservice:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings />
<system.web>
<compilation targetFramework="4.5" />
<httpRuntime targetFramework="4.5" />
</system.web>
</configuration>
WCF completely replaces ASMX web services. ASMX is the old way to do web services and WCF is the current way to do web services. All new SOAP web service development, on the client or the server, should be done using WCF.
There's a lot of talks going on regarding the simplicity of asmx web services over WCF. Let me clarify few points here.
Its true that novice web service developers will get started easily in asmx web services. Visual Studio does all the work for them and readily creates a Hello World project.
But if you can learn WCF (which off course wont take much time) then you can get to see that WCF is also quite simple, and you can go ahead easily.
Its important to remember that these said complexities in WCF are actually attributed to the beautiful features that it brings along with it. There are addressing, bindings, contracts and endpoints, services & clients all mentioned in the config file. The beauty is your business logic is segregated and maintained safely. Tomorrow if you need to change the binding from basicHttpBinding to netTcpBinding you can easily create a binding in config file and use it. So all the changes related to clients, communication channels, bindings etc are to be done in the configuration leaving the business logic safe & intact, which makes real good sense.
WCF "web services" are part of a much broader spectrum of remote communication enabled through WCF. You will get a much higher degree of flexibility and portability doing things in WCF than through traditional ASMX because WCF is designed, from the ground up, to summarize all of the different distributed programming infrastructures offered by Microsoft. An endpoint in WCF can be communicated with just as easily over SOAP/XML as it can over TCP/binary and to change this medium is simply a configuration file mod. In theory, this reduces the amount of new code needed when porting or changing business needs, targets, etc.
Web Services can be accessed only over HTTP & it works in stateless environment, where WCF is flexible because its services can be hosted in different types of applications. You can host your WCF services in Console, Windows Services, IIS & WAS, which are again different ways of creating new projects in Visual Studio.
ASMX is older than WCF, and anything ASMX can do so can WCF (and more). Basically you can see WCF as trying to logically group together all the different ways of getting two apps to communicate in the world of Microsoft; ASMX was just one of these many ways and so is now grouped under the WCF umbrella of capabilities.
You will always like to use Visual Studio for NET 4.0 or 4.5 as it makes life easy while creating WCF services.
The major difference is that Web Services Use XmlSerializer. But WCF Uses DataContractSerializer which is better in Performance as compared to XmlSerializer. That's why WCF performs way better than other communication technology counterparts from .NET like asmx, .NET remoting etc.
Not to forget that I was one of those guys who liked asmx services more than WCF, but that time I was not well aware of WCF services and its capabilities. I was scared of the WCF configurations. But I dared and and tried writing few WCF services of my own, and when I learnt more of WCF, now I have no inhibitions about WCF and I recommend them to anyone & everyone.
Happy coding!!!
What benefits does WCF bring to the table and why should I use this new technology over good old ASP.Net web services?
Maybe you don't need to transition to WCF if regular Web-Service will work for you,
however WCF encompasses more than just Web-Services.
With WCF you can utilize different communication channels (such as Web-Services, MSMQ, named pipes...) utilizing the same end-point service handler code.
WCF also has different built-in security mechanisms, allows you to utilize different serialization mechanisms (if something other than Soap is needed like raw JSON), hosting of services without the requirement of needing a web project etc...
As such WCF is more a general service hosting framework that can replace regular ASMX web services
Here is a good article from msdn that talks about the differences between ASMX and WCF
A few key areas
Serialization - Asmx uses XmlSerializer while WCF uses the DataContractSerializer. The Datacontract serializer is about 10% faster (source along with other information)
Differences Between ASMX and WCF Services
Greater protocol support (HTTP, TCP, ICP, MSMQ for WCF), ASMX only supports HTTP
I'm building a workflow app to investigate the technology. I can't decide whether to go for a web service (and a technology with which I'm basically familiar) with WebServiceInputActivity's or WCF and ReceiveActivity's (and a new technology that I'll have to learn).
Are there any major reasons to go either way?
Clarification:
Are there any major (architectural) reasons relating specifically to WF to go either way? I appreciate the input of the respondants, so far, but they focus on WCF rather than what the implications are for my workflow and its lifetime, maintainability, performance, expandability, etc. if I choose WebServices or WCF.
WF and WCF are very much hand in hand in .net 4. I'd definitely suggest the latter.
No doubt, it is WCF. Migrating ASP.NET Web Services to WCF
SUMMARY: Windows Communication
Foundation (WCF) provides a unified
framework for rapidly building
service-oriented applications that
makes it easy to build and consume
secure, reliable, and transacted Web
services. WCF’s single programming
model unifies the capabilities in
ASMX, WSE, Remoting, COM+, and MSMQ;
therefore developers need to learn
only one programming model.
Agree with the others here that you should go with WCF.
Just thought to add one more point, that just because you use WCF does not mean that you cannot access existing web services. You can use a WCF client with basichttpbinding, to access existing non WCF web services.
You are making a mistake to call ASMX web services "web services" and suggesting that WCF can't be used to make web services. A WCF service using basicHttpBinding is exactly like an old ASMX service.
The best reason to use WCF instead of ASMX is that Microsoft has now stated that ASMX is a "legacy technology", and that they will not be fixing bugs in it.
I am learning wcf but I have trouble understanding the benefits. Is there ever a time I would want to use traditional web services?
I read another thread with these benefits:
Opt in model for members using a certain attribute
Better security
No need to worry about binding (can't understand how this is true)
No need to worry about the xml
I read Programming WCF Services however this was an advanced book a bit like CLR via C#. I am now reading Learning WCF Services and will read Essential WCF (is recommended).
What would happen if I use a normal class to try to talk to a web/service reference? I know this sounds really naive, it's just my lack of experience in web services.
I am coding some WCF services so I am getting exposed to the specifics. They are interacting with a SOAP web service provided by my web host so I can get stats on my site. Is there anything wrong in this approach?
Thanks
WCF is a unified programming model for developing connected systems. What this means is that you use a single framework to develop service-oriented solutions. WCF allows you to keep your service implementation relatively unaware and care free of what's going on under the covers as far as how your service is consumed by clients and communication is handled. This allows you to take your service implementation and expose it in various ways by configuring it differently without touching your service implementation. This is the unified part. Without WCF, you have to get familiar with a framework specific for a particular communication technology such as ASP.NET asmx web service, .NET remoting, MSMQ etc and usually those frameworks impose on your service implementation and creep in such as using WebMethod attribute or having to derive from MarshallByRefObject object etc and you just can not take your service implementation and easily expose it over another communication stack. If I have a service that adds two numbers, why can it not be exposed over http or tcp easily without having to worry about low level details? This is the question in your post regarding binding. Binding allows you take a service and configure it so that it can be exposed over different transports and protocols using different encodings without ever touching your service implementation.
Is there ever a time I would want to use traditional web service?
Web service uses well defined, accepted, and used standards such as HTTP and SOAP. So if you want your service to be consumed by wide range of clients, then you would want to expose your service as a web service. WCF comes with pre-configured bindings out of the box that allows your service to be exposed as a web service easily: basicHttpBinding and wsHttpBinding. You may also want to consider RESTful services which is an architectural style that fits more natural with the HTTP model. WCF supports RESTful services as well
What would happen if I use a normal
class to try to talk to a web/service
reference? I know this sounds really
naive, it's just my lack of experience
in web services.
WCF service can expose the wsdl for a service just like ASP.NET asmx web service does. You can generate a client side proxy by simply adding a service reference to your client project. There is also a command line tool called svcutil that also generates the client side code that allows you to easily communicate with the service. The client side service class basically mirrors the service interface. You create an instance of the client side proxy for the service and then simply call methods on it just like any other .NET object. Under the covers, your method call will get converted to a message and sent over the wire to the server. On the server side, that message will get dispatched to the appropriate service method.
I hope this helps a bit.There are lots of online content such as videos on MSDN and channel 9 that you check out. The more you pound on it and expose yourself to it, the clearer WCF will get I am sure. Also, WCF is THE framework Microsoft recommends to develop connected system in .NET. The other technologies ASP.NET asmx, WSE, and .NET Remoting will most likely still be available going forward but may not be supported and developed further.
There are a number of existing approaches to building distributed applications. These include Web services, .NET Remoting, Message Queuing and COM Services. Windows Communication Foundation unifies these into a single framework for building and consuming services.
Here is a link from MSDN Why Use Windows Communication Foundation?
WCF is really the "new" standard and new generation of web service - and even more generally, communications - protocols and libraries for the .NET world.
Whenever you feel the need to have two systems talk to one another - think WCF. Whether that'll be behind the corporate firewall in your company LAN, whether it's across the internet, by means of a direct call or a delayed message queueing system - WCF is your answer. Mehmet has written a really nice summary of how WCF is the unification of a great many communication standards that existed in the Microsoft world before WCF.
I would think with the "Learning WCF" book, you should be a lot better off than with Programming WCF - that's quite advanced stuff already!
One of the mainstays of WCF is the architecture that you always talk to your service through a proxy - whether that service runs on the same machine using NetNamedPipe binding or halfway around the world in Down Under on a server - no difference, you always go through a proxy. That then also allows WCF to be so extensible - thanks to the proxy always being between the client (your application) and the service, it offers excellent ways of extending the behavior and the inner workings of WCF to your liking and needs.
WCF basically builds on SOAP communications - so interfacing and using existing SOAP services should be no problem at all. With the WCF REST Starter Kit and in the upcoming .NET 4.0 release cycle, WCF will also extend its reach into the REST style web communications, if that's ever going to be a requirement of yours.
All this really shows one of the biggest strenghts of WCF: it's a unified and extremely flexible and extensible communication framework, that can handle just about anything you throw at it. That alone is more than enough reason to learn WCF (which can be dauting at first, I agree!), and you won't regret the effort you put into this endeavor.
Marc
Have you a specific application you are writing for, or just getting your feet wet?
Google protocol buffers, is a very good choice of communications. John Skeet & Marc Gravell have both done C# implementations. See here
I need some direction related to this topic; maybe I am missing the obvious.
I dont see a contrast between WCF bound to HTTP and strongly typed web service. Why would this be any different?? I agree there are some development nuances especially related to XmlSerializer in ASMX vs WCF and a plethora of Microsoft jargons. Short of these; i only see parallels
DataContract=WSDL Type
ServiceContract=WSDL (aka service definition)
OperationContract=WebMethod
Operationally, I understand the binding can be numerous with WCF instead of getting locked down to HTTP, which can involve heavy construct and tear down. But for loose coupling it will all be web services.
Are there other operational differences??
Can someone show me the light and put me out of my misery?? :))
Well, if you reduce your discussion to only HTTP, then there's still a slew of advantages that WCF has over ASMX:
more and better security settings (ability to use either transport or message security)
much more flexibility - a lot more can be configured and tweaked in WCF, either in configuration files or code
ASMX web services can only exist inside IIS - IIS is a must-have requirement; you can self-host your WCF services in a console app or Windows NT Service
the clear focus on using Service and Data Contracts in WCF makes for a much cleaner interface and a much better separation of concern (better code, in the end)
support for things like reliable messaging and transaction support (even over HTTP)
In short: even though the differences might be smaller when you restrain WCF to just HTTP, I still think it's superior and if you have the choice to start something new today, by all means, use WCF instead of ASMX!
Rick Strahl puts it very nicely in his blog post:
I would argue that using WCF for any new services is probably a good idea even if you stick with pure HTTP and SOAP because by creating your service with WCF you can decide later on to publish this same service using WAS and also provide the more high performance TCP/IP transport. Or you might be asked to provide some of the advanced features of WS- protocols like transactions, attachments, session management, encryption etc. By using WCF you are building your service with a view to the future so you can easily move up to other protocols-some of which may not even exist today. Certainly new technologies will come along in the future and WCF protects you somewhat through its abstraction layer and common API.*
Marc
Another point for the consumers of the ASMX web service, which ever platforms will consume the web service will have to implement a SOAP stack. If you're goal is for wide reaching consumption, WCF is preferable and will allow you to expose the WS in more universal ways.
The other big distinction between the two technologies is that Microsoft now considers both ASMX web services and XML Serializer to be "legacy technology", and is no longer fixing bugs in them.