I'm just wondering how to approach to my project.
In my application I have:
MVC4 project
DB_Project with Interfaces and Models
Repository_Project with interfaces implemantation - I'm using Ninject
Next step is mobile app(XAMARIN), and here is the question:
What kind of WCF project should I choose and why...WCF Service Application or WCF Service Library?
Should I add this project like any other or create separate one?
After choosing WCF project, how to use reference to Repository_Project - is this the right way?
I will give you some thoughts to consider.
1- Your Xamarin app must communicate with an asp.net web api / mvc exposed to the internet. I dont recommend exposing a WCF service to the internet for many reasons.
2- In the Data layer, repositories are abstractions to access your EF dbContext and not to call WCF services.
3- You only add complexity when justified. If you are willing to create WCF project for the xamarin app to communicate with, then i hardly discourage you. WCF project may be created in your case if you have some security policy that enforces 3-tiers architecture where the web api needs a middle tier to access the database. Otherwise, you dont need it.
2-tiers:
Xamarin -> web api -> SQL Server
3-tiers:
Xamarin -> web api -> wcf -> SQL Server
Related
I want to build a new mobile app backend. This backend might eventually support other types of clients such as desktop or traditional web application.
In the past for multi client applications I would use this stack of technologies. SQL Server -> Entity Framework -> TCP WCF Service Endpoint -> MVC Web Application or WPF Windows Application
I know I want my mobile client to be consuming a Restful Http Web API like the types you would host in the new Azure API product. But I'm not sure if I should still do the WCF layer or not.
Couldn't all my clients consume just the Web API now? Or would it still be wise to develop the WCF service and the layer Web API on top of that?
It just doesn't seem right to be using 2 different serialization technologies at the same time.
Yes, you could replace that with Web API and create a REST API but as Tim already mentioned on his comment, that is obviously just HTTP and not all the protocols WCF supports.
Having said that, API Apps have Swagger metadata to describe what the REST URIs (endpoints) can do (e.g. methods, content types, descriptions etc.). There are a lot of Swagger SDK generators which can read the Swagger metadata and generate the code you need to consume the REST API in your application for pretty much any language out there. For Visual Studio 2013 with the latest Azure SDK, you have this capability built in as well. This is pure code generation, no tight coupling or anything, we just generate the code you were supposed to write to consume the API.
I need some advice about using WCF or DLL in my program. I am developing a program that will be Desktop App and Web App. The architecture is multi tiers. What should I do in Bussiness layer, should I just make it as a namespace and build it to be a dll then in my Desktop App and Web App I add reference this dll OR should I make the business layer be a web service, then I can use in my apps. What I have to consider when using a web service instead of dll.
Just to get started you could create one Solution that includes:
Business logic project
Web App project
Desktop project
Web App project and Desktop project will just reference your Business logic project. Then(if needed) you could continue to separate Business logic project to e.g. Data Access project, Service Layer project etc.
Then if you will feel that you need "real" WCF service it would be easy to create one from your decoupled architecture.
You should use restful service like http webapi which has broad reach of clients
I am learning to create RESTful services using WCF. There are a myriad of options to choose from. I am confused as to what should i use.
1.)REST Starter kit - Seems to be obsolete
2.)WCF WEbhttp service
3.)WCF Web API
4.)ASP.NET web api
I dont want to use ASP.NET MVC to build RESTFul services. I dont like the idea of services being in the same solution structure of a presentation layer. So what is it i should use?ASP.NET web api seems to be having going down the MVC route where the requests are handled by a controller which i feel does not fit into a "Service" terminology.
Take a look a that
Microsoft support for REST is moving to ASP.NET WebApi, but you are still free to use webhttpbinding to build your api if you want. The starter kit is no longer developed nor supported.
I don't get this part though
I dont like the idea of services being in the same solution structure
of a presentation layer.
You can build a webapi project in a different assembly than your web (presentation logic) project, and the solution it's only useful for you to keep all the things in one place, it does not affect the behavior of your projects/assembly, you can still use them/develop them independently. If you don't like the "style" of webapi (it's certainly "different" from what WCF developers are used to) it's another story.
i am new to the concept of silverlight and understood few things from this site.
i want to clear my doubt that what is the role of wcf ria services in silverlight applications?
what do we mean by domain services?
In Silverlight, you do not connect to a database directly - your Silverlight app runs on the client machine after all. The client-side UI (Silverlight) and the database / backend are strictly separated. The number of classes that the Silverlight runtime has to offer is (by design) quite limited, and things like direct database access are not amongst those classes available.
The way your SL app gets its data is through a WCF service (Domain service, or WCF Data Service) running on some server, which accesses the database on your behalf. This part usually runs on your web/app server and has access to your database or other backend servers.
The domain services are the one who gives you access to a remote repositories using WCF technology. That Silverlight compact .Net framework is on the clientside which needs to access services through cloud (internet) in able to interact data to the users.
You can start in http://www.silverlight.net
Happy reading!
I have a MVC pattern in place where I have been developing WinForms and WebForms against. Now, I would like to move onto Silverlight and thus need to 'web services'-enable my Model layer.
Where do I start? I can't seem to find any good resources. Many talk about EF or ADO.NET Data Services. What do I need to do to my Model layer to enable it for WCF REST?
There are many approaches you can take to build your server-side
ADO.NET Data Services - here is some documentation
ASP.NET MVC - if you do decide to use ASP.NET MVC, then this tutorial shows you how to access the service from Silverlight. Essentially Tim is showing you how to access the particular REST service exposed by ASP.NET MVC, but the same techniques (WebClient, etc) can be used to talk to any REST service
Build your own WCF SOAP-based service which implements the MVC pattern. This link shows you how to build and access WCF SOAP-based services in Silverlight.
Build your own REST service which implements a MVC pattern. There is a universal way to comsume any REST service from Silverlight, which is described here. To build the rest service you can use whatever platform you choose. You may consider the WCF REST support that comes out-of-the-box in .Net 3.5, or the WCF REST Starter Kit, which builds on the out-of-the-box REST support in WCF to give you some extra features. Or you can consider any other REST service framework of your choosing.
If you are going to proceed with the technologies you are talking about then forget completely about the term REST. What these technologies allow is you to do is object remoting over HTTP with the HTTP verbs. There is nothing wrong with that, just be aware of what you are trying to achieve.
The more you read and understand about REST the more confused you will get while trying to use Silverlight 3, ADO.Net Data Services, WCF REST Starter kit. These are all fine technologies to achieve what they were designed to do. Unfortunately, you will not learn how to do REST properly from these tools.
If you really want to do REST in .Net then start looking at OpenRasta.