I'm developing an iOS/Objective-C Enterprise application that needs access to a SQL Server back-end via a hosted C# service. WCF is the obvious choice for the plumbing, but like most Microsoft development technologies, once you get beyond a simple demo app, it gets pretty ugly.
I came across ServiceStack and it looks much nicer than WCF. It worries me that I can find almost no references to anybody else using an iOS/Objective-C client (although I do see a couple references to iOS/Mono ServiceStack clients).
ServiceStack is clearly focused on standard protocols so i'm sure it can do the job, but I have the nagging feeling that I'm missing something. Am I trying to drive nails with a blender or something?
What's the mainstream solution for iOS/Objective-C developers connecting to a back-end SQL Server database?
From the outside you can think of ServiceStack as just shipping clean JSON over the wire, although ServiceStack does provide a nice story for .NET clients by being able to share typed DTOs to provide an end-to-end Typed API for free, i.e. without any code-gen or additional effort. The web service output itself is clean and doesn't have any coupling to ServiceStack and can be easily consumed with the standard JSON or XML serializers in each of the respective platforms.
The swedishstartupspace.com recently posted how they built their winning SLussen iOS mobile app in a day at the Uppsala Hackathon. They used the native iOS RestKit library to consume their back-end ServiceStack API.
Others have used Xamarin.iOS front-end to build native iOS apps in C#, there's also a course on PluralSight showcasing how to use c# to develop Xamarin.iOS native mobile apps talking to a ServiceStack back-end.
Related
I have been looking up on youtube regarding Web Services being consume using android. Most of the video are all 1 or 2 years old. Is this doing outdated? is there a better way to do this? currently i am in a company and i was assign to have a android version of their webservice.
I was told to create the service with sql using Visual studio.
Create the android UI and using the services to pull the data.
Am i doing it right?
What is the better or ideal way of going about this?
Should i add JavaScript or something like that?
I have been looking at RESTful , Soap , Json and Wcf. But what is the best way to go if i have to start everything from scratch?
-Programs/System that i am using.
Microsoft Visual Studio Express 2013 for Web
SQL server
IIS express
Android Studio
*I was told to only user framework 4.0 for Visual studio
You can use WCF (SOAP), WCF (RESTful) or WebApi to create a service, both has it's own advantages and disadvantages. You may want to take some time to look at your requirement and then decide what type of service you want to develop. SOAP uses a more complicated messaging pattern using XML, where as REST uses the standard HTTP protocol and methods to communicate and transfer data. But if you are planning consume this service across of variety of applications like mobile, web, desktop, client side script interaction etc, you may consider developing the service as a RESTful. More information on SOAP and RESTful and for detailed understanding you may refer to this link
Understanding SOAP and RESTful
I have an Existing Web application builded two years ago with VS2010 ASP.NET Web Forms, C# and SQL SERVER 2008 .Now i want to build mobile version and install it in mobile devices. I want to develop it using JQuery Ajax, Jquery Mobile and Apache Cordova. My simple question is how can build serialize from database json REST api/webservices in vs2010 or vs2012 that will consumed by ajax clients in mobile devices ???
Thanks to all
I would recommend you for WebAPI. because of following reasons.
If we need a Web Service and don’t need SOAP, then ASP.Net Web API is best choice.
It is Used to build simple, non-SOAP-based HTTP Services on top of existing WCF message pipeline.
It doesn't have tedious and extensive configuration like WCF REST service.
Simple service creation with Web API. With WCF REST Services, service creation is difficult.
It is only based on HTTP and easy to define, expose and consume in a REST-ful way.
It is light weight architecture and good for devices which have limited bandwidth like smart phones.
It is open source.
Tutorial is here.
http://channel9.msdn.com/Events/Build/2014/3-603
Save yourself a lot of coding, and use SlashDB. http://www.slashdb.com/how-it-works/
It will automatically make a web API for an existing database. Your case is very typical because many websites use server-side templates to make dynamic HTML, which of course does not work well if you need a native app or a highly responsive HTML5 mobile page.
Disclosure: I am the founder and CEO of the company behind SlashDB, but you don't have to take my word it - just try it.
I come from a RubyOnRails background so sorry if this looks like a silly question:
Let's say we are creating our app in ASP.NET MVC and we need to develop some RESTful web services to give us some JSON that we can use in our app.
How do you create those services? Is it WCF ?
In Ruby we actually used Java-Jersey for the service side but in my current work place it is a .NET shop with strong experience in Silverlight and RIA Services. so what is the NET approach of web services for ASP.NET MVC ?
WCF is a super powerful but incredibly complex communication framework that allows systems to talk over multiple protocols. It sounded cool during Microsoft's initial pitch, but there is an incredible amount of overhead just to, say, push a scalar across the wire. WCF certainly still has its place, but it's a beast of a framework.
Given how much effort there is in integrating it into a solution, some MVC developers noticed that, Hey! I can just return a JsonResult from my MVC controller and have my AJAX scripts consume that. Quick and dirty!
Microsoft then refined the experience with Web API, which is focused solely on developing HTTP services. It's architected quite similarly with MVC, which makes it pretty darned easy to pick up. It is typically RESTful, but doesn't need to be. By design it works really, really well with HTTP - remember, HTTP is an application protocol as well as a transport protocol.
There is also neat stuff like how it takes care of serialization for you - if the client wants XML, Web API gives it XML. If the client wants JSON, Web API gives it JSON. With a little work, you can even come up with custom serialization formats!
So, before I go off on one of the many tangents about how awesome sauce Web API is, let me say that if you are looking for a simple, powerful framework that can deliver RESTful services over HTTP, then Web API is your solution.
http://www.asp.net/web-api
I am a total newbie to the WCF world. I have an ASP.net (v4) website running on our dedicated windows 2008 server box. I'll refer to the website as, webisteA.com
I'm creating a new website, websiteB.com.au and I'd like to expose the functionality in WebsiteA.com to the new site. Things like logging in, registering in the database etc.
I think the best way to do this is to create a WCF service which sits in WebsiteA.com - but I am struggling to find any tutorials on how to do this. There are lots about creating a new project, but not that many about adding a WCF service to existing websites.
Is this the best way to do it? In the future I'd also like to use the service for mobile apps in the future too - not sure if that will make a difference.
OR - do I create a new service in a new app which is totally seperate to websiteA.com and websiteB.com and host this as website0.com and expose the database via that?
The questions I don't have answers for are...
is it restful? Do I use XML or JSON?
Baiscally, I want to be able to use it like an API - for example, saying "show me all the members who meet criteria X".
Thanks for any information.
ps) I have visual studio express 2010 c# (and a trial of studio pro)
You can certainly include WCF within the website A project - but have you considered the ASP.NET Web API? I haven't used it yet - but did use the earlier WCF Web API which spawned it.
Neat features include Content Negotiation (if the client asks for XML the API sends XML. If it asks for JSON is gets JSON) and a lot less config cruft (WCF web.configs are dreadful and completely overcomplicated IMO)
It's probably a lot easier to make a RESTy API with the ASP.NET Web API than with standard WCF.
A great open-source .NET solution is NancyFX which is really worth a look too.
Following the KISS principle, I suddenly realised the following:
In .NET, you can use the Entity Model Framework to wrap around a database.
This model can be exposed as a web service through WCF.
This web service would have a very standardized definition.
A client application could be created which could consume any such RESTful web service.
I don't want to re-invent the wheel and it wouldn't surprise me if someone has already done this, so my question is simple: Has anyone already created a simple (desktop, not web) client application that can consume a RESTful service that's based on the Entity Framework and which will allow the user to read and write data directly to this service?
Otherwise, I'll just have to "invent" this myself. :-)Problem is, the database layer and RESTful service is already finished. The RESTful service will only stay in the project during it's development phase, since we can use the database-layer assembly directly from the web applications that are build around it. When the web application is deployed, the RESTful services are just kept out of the deployment.
But the database has a lot of data to manage over nearly 50 tables. When developing against a local database, we can have straight access to the database so I wouldn't need this tool for this. When it's deployed, the web application would be the only way to access the data so I could not use this tool. But we're also having a test phase where the database is stored on another system outside the local domain and this database is not available for developers. Only administrators have direct access to this database, making tests a bit more complex.
However, through the RESTful service, I can still access the data directly. Thus, when some test goes wrong, I can repair the data through this connection or just create a copy of the data for tests on my local system. There's plenty of other functionality and it's even possible to just open the URL to a table service straight in Excel or XMLSpy to see the contents. But when I want to write something back, I have to write special code to do just that. A generic tool that would allow me to access the data and modify it would be easier. Since it's a generic setup around the ADO.NET Data services, this should be reasonable easy too.
Thus, I can do it but hoped someone else has already done something similar. But it appears that there's no such tool made yet...
You are referring to ADO.Net Data Services. It basically creates an Entity Database Model and adds a REST frontend to the service using ASMX. There is a How To article availble from MSDN here on consuming the service using .Net. I have also done the same thing using the normally WebClient class in .Net in the past.
You can also look at the WCF REST Starter Kit if you want to roll your own based on Entity Framework. The starter kit also contains a handy new WebClient class that can be used to communicate with REST services.
Clarification
There is no prebuilt application client that I am aware off which will talk to these service, since they are pretty much accessing the data using Web Services. There is the Microsoft Smart Client Factory which is most likely the closest thing I have worked with.
I mentioned the above 2 options since they already have libraries in .Net that work with them directly, either as a referenced Web Service, or for the more adventurious, myself included, using the WebClient library or alternatively the new HTTPClient library in the WCF REST Starter kit.
I have used both, in Windows, Web, Silverlight and WCF. The latter being the easiest since they are focussed at REST.
We are currently investigating Prism which strongly leans to using this method when using WCF for front-end development.
Assumption
With regards to this question, you are making a generic assumption that wrapping ADO Entity Framework with a WCF service it will be generic. ADO.Net Data Services is the closest you will get, however the structure of the database will fundamently change the way you interact with it. Going a level higher in a "generic" way would be dangerous, as these 2 technologies, individually or together, are already as generic as possible.
In addition to Data Services (+1), consider RIA Services. It's like a domain-specific version of data services for Silverlight or WPF clients. Less flexible, but easier, than Data Services.