I'm new to this kind of development, and so far I've only seen tutorials on WCF RIA services which create new ADO.Net data models from a database.
However I am working with a system which provides you with web APIs for interacting with the data (which I am able to contain and use in my own web service, which will in turn interact with my silverlight application).
Is it possible/sensible to use WCF RIA services in this case? Or shall I just use a regular WCF Service which uses these APIs?
Thanks!
I think you should first really understand the power of WCF RIA Services as explained in the msdn documentation http://msdn.microsoft.com/en-us/library/ee707344(v=vs.91).aspx
"A common problem when developing an n-tier RIA solution is coordinating application logic between the middle tier and the presentation tier. To create the best user experience, you want your RIA Services client to be aware of the application logic that resides on the server, but you do not want to develop and maintain the application logic on both the presentation tier and the middle tier."
So, as soon as you are in the domain service, you are in a classic WCF Service, so here you could interact with possibly anything you wish (including external web API).
Though, the avantages to use WCF RIA Services is smaller if the logic of your application is already embed in a Web API.
Related
We are starting a new project and trying to implement some concepts from Domain driven design. We are planning to have following layers:
Web Interface (WebAPI)
Application Services (library)
Domain Services (library)
Data Access Services (Library)
We are thinking about merging Web interface and Application service together. So, our webAPI will be talking to repositories, domain model and domain services.
Is this fine or should we have separate project form application services and WebAPI should only communicate with Application services?
Thanks
HTTP should be seen as one of potentially many access ports to reach your application services. If you could be entirely sure that you will never have to speak to your application through another communication channel than HTTP then I'd say it's perfectly not to have a seperate application layer.
However, I'd also say that it's very hard to predict how application needs will evolve and since adding an additionnal layer of indirection to segregate the application layer right away shouldn't be very costly (it's just delegation) that's what I'd do.
I am doing research on an application that needs web application as well as mobile app and am considering to use Azure App Service.
In the current implementation, we need to write the same logic in mobile app and as well as in web application. I want to use the same repository and database for both the endpoints. But I don't want to write the same code for the business logic in two different places.
How can I mix web application and mobile app using the same repository, database, and business logic ?
If Web API is used I can create a service layer which can be used both in Web API and MVC 5 application. I want a similar system to that.
You've already got your answer, ie. use APIs. If you structure your solution in a decoupled architecture, you'll be able to write as many front ends as you like, reusing the same back end services. Consider a web app and mobile app to be front ends - they should be presentation layers only with minimal logic for controlling the UI, and no business logic. A typical solution that decouples in this way would look like the below. Use interfaces to describe the APIs, so you can easily mock, refactor or re-work back end services without effecting the apps which consume the APIs.
Web App
Mobile App
API project (WebAPI/REST recommended)
Interfaces to the services
Business services (reusable, long lasting, robust and well tested/testable)
Repository (to abstract the db connection)
Other abstractions (web services, other services/systems)
So your business logic can be written once, and fronted by the interfaces and/or the REST api, which is called by your separate web apps/mobile apps. If you use a web api as the mechanism to join the apps to the services, you will have one physical deployment of your business services; if you just use interfaces, you will need to deploy your binaries to each instance (web apps, mobile apps, etc)
I am working on a Visual Studio Application that references a WCF web service, and after some reading online I am pretty confused.
I have read that WCF is a framework for building a web service, but it is not an API. Is this true?
I was under the impression that Web Services are APIs; I always thought that APIs were Software as a Service (SaaS). Doesn't that mean that APIs and Web Services are pretty much the same thing? Or do I have the wrong idea?
Could this be a misconception of my understandings of SOAP and REST?
Basically I want to know whether a WCF built web service counts as an API, and why/why not?
WCF is an API that can be used to create APIS within your application.
Web Services usually involves creating an API within your application. There are valid APIs that are not Web Services, like the Win32 API.
Its possible to build a WCF web service with one web method for an application that would not be considered an API specifically since it does not contain a set of routines, protocols, or tools for building applications.
Review http://en.wikipedia.org/wiki/Application_programming_interface for what an API is.
According to wikipedia, yes, yes it is:
APIs often come in the form of a library that includes specifications
for routines, data structures, object classes, and variables. In other
cases, notably SOAP and REST services, an API is simply a
specification of remote calls exposed to the API consumers.
An API (Application Program Interface) is a way to interact with components of a system. It defines the operations that can be used to get data out or push it in.
WCF (Windows Communication Foundation) itself is a framework for building web services and other applications that need a communication channel to share data with other services/applications, it is actually a lot larger on what it can do. You can read more about it on MSDN. It is an API as it gives you objects that allow you to tell it interact with its' components.
REST and SOAP are just architecture styles that can be used to serve data via a service, it is defining how you should interact with the data rather than the components themselves.
My company currently have web services written in WCF in C#, I have been asked to adjust my interface to interact with the web services, the interface is written in PHP/HTML. It will be running VIA IIS as well as the services.
Is this possible or do I need to tell me boss we need to go back to the drawing board
WCF Services can be accessed by any other application that is built on any platform and using any programming language.Web services are interoperable.
You can either expose a REST endpoint:
http://msdn.microsoft.com/en-us/magazine/dd315413.aspx
Or just put a ASP.Net Web API in front of your WCF service to act as a middle man:
http://www.asp.net/web-api
In php there are a number of ways of talking to a RESTful service, here is one library that can help:
http://phphttpclient.com/
We have an application in which we have created a service layer with most of the business logic and utility services (logging, exceptions, caching etc). We have to come with a way to expose this service as an API to the UI components. Here are some of our requirements:
We would like to create multiple
components based on the service.
We would like third party developers
to use our service to create their
own components or utilize our data.
For scalability we would like to have
a multiple instances installed on
different boxes. Similarly there
could be more than an instance of the
same UI component.
One way to expose the service layer is to host it under a REST based WCF layer.
The other way is to host the service in model layer of an ASP.Net MVC project. The UI components will be hosted in MVC projects of their own. The Javascript in the views of UI components will directly call the controllers of service project.
WCF is supposed to be very heavyweight option. On the other hand I am not too convinced with the MVC approach as I feel that this is not purpose it is meant for.
Could you please recommend me a way in Microsoft world to expose our service layer.
WCF seems to be the way to go here. Although WCF started out (in my oppinion) as a beast, it got tamed over the years with better HTTP and JSON support and less custom configuration (although still allowing you to modefy basicly every little aspect of your service).
Exposing your current service layer as a REST Service is a breeze and allows your customers/yourself to easily consume it on any device that supports HTTP.
See: http://codebetter.com/glennblock/2010/11/01/wcf-web-apis-http-your-way/
Models are not services. Models are POCOs that hold data.
You can expose your service through a WCF Service, and let your ASP.NET MVC app consume it. If you're always sure that the service will run on the same box as the client app, you can use named pipes for transport -- then the overhead of WCF is minimal, compared to the advantages.
WCF seems to be the direction that Microsoft is headed for this and for good reason. WCF services are the best option here because you mentioned third-party development support. Because these web services are defined by a WSDL, they are cross platform and can be consumed by non .NET applications.
It perfectly seperates your service layer to be consumed by ANY components.