I want to access a remote SQL database for my Silverlight client. I know that there are various ways to do this (Entity Framework model, Linq to SQL), but all of those rely on something in the web project (or, at least, all of the tutorials I've read do). What's unusual for me is that there is no web project, which of course prevents me from using various assemblies.
The only thing I do have which might be useful is a WCF service running on IIS, which will have less limitations (and I can add that as a service reference in my SL project). But I'm not even sure if this is a feasible option for this problem.
Any solutions or suggestions would be great.
Thanks.
Edit: Thanks for the suggestions guys, but here's a little more: I am making an individual XAP that is loaded into something else (someone else's project is importing and loading the XAP files), so I don't have access to the web component. The loader itself will be hosted within a website (at least, I assume it will be).
I already have a WCF service set up which is currently hosted in IIS, so I can potentially create something here. How? Well, it seems I can generate the ORM classes using SQLMetal.exe, and then import that code into the WCF service. This will allow the service to make calls to the remote database and have that data returned in C# classes. The perhaps I'll make those data classes as ServiceContracts and pass the data that way. What's the problem here? Well, to be honest, I'm not really sure how it would work. I mean, I call the WCF Service from the SL application, which does its thing. It then must contact the SL application (I have no idea how to do that part) and send along a load of data. It would be great if someone had has experience of this and would offer some suggestions. I know it's not really how you're supposed to do it, but I've drawn the short straw so I'm stuck with it.
Ok, so if I understand it correctly, you use a Silverlight application (XAP) which is started locally from a network share or something? Because why would you not have a web project when using Silverlight? (is there no server available to host it?)
But ok, when that is the case, you can access a WCF service from Silverlight. However it has some limititations. For instance you can only use asynchronous calls to the service, and you can only use WCF basichttpbinding as binding for the WCF service.
See: http://msdn.microsoft.com/en-us/library/cc197959%28v=vs.95%29.aspx
First, I would recommend you use WPF instead of Silverlight for this project. If you're not using this as a web client, then WPF is a million times easier / better.
But if that's not a possibility:
You can write a self-hosted WCF service and run it somewhere accessible. Self-hosted will allow for WCF connections to connect without the IIS necessary. In your self-hosted program you need:
Front end WCF defined
Back end SQL database
Depending on how smart this client needs to be, a BusinessLogic layer to transform the data from WCF to SQL.
Silverlight is sandboxed, so it can only access its own Web application. Therefore, your best bet is to include a WCF or ASMX web service in your web application that handles the DB access.
If you don't want to run a sandboxed UI on a Web application, you cannot use Silverlight but should use WebForms or Windows Presentation Foundation (WPF) instead.
Related
I'm looking at converting an existing web service into a Web API. I've only worked with a WS a little bit and it was a long time ago. What I do remember is that in my project I would make reference to a service location and then use that reference to call whatever method I needed.
EX: I would reference http://mydomain/webservicename/mobile.asmx and then would call objWS.MethodName() what was coded within the mobile.asmx file.
If I convert over to using a Web API I would basically call the HTTP by going to something like http://mydomain/controllername/myMethod.
As of right now I don't have access to the client code to be able to change the way that it calls the service. That being said am I stuck with using a traditional web service vs web api?
This is an app on a handheld scanner that I believe is running Windows CE. We are having some connectivity issues/database deadlocks and I was asked to look at it and see if I can help out. The current WS code is overly complicated IMO since it's only doing either an insert or an update to a database. I would also think that going with a Web API would make it a faster app since it's depending on cellular access for it's communication. JSON should be a smaller payload than XML.
So, I would like to just re-write it using Web API 2 and Entity Framework. However, I'm afraid I'm stuck to using WS since I don't have access to the client code.
Any suggestions?
It's a fairly broad architectural suggestion, but what you're proposing certainly sounds possible and even quite reasonable.
If I understand correctly, you currently have this:
Client -> ASMX Service
And you can't change the Client, only the ASMX Service. The first thing you're going to want to do this ensure that server-side business logic is de-coupled from the platform technology:
Client -> ASMX Service -> Business Logic
The idea here is that any application host should be able to reasonably invoke the same business logic, even if that logic is nothing more than direct database access. The application host itself should be little more than a pass-through set of operations to be invoked.
At that point, you can create a second application host alongside the first one:
Client -> ASMX Service ----|
|-> Business Logic
WebAPI Service --|
So now you have two different services which expose the same business logic, using two different web service technologies. Each of them should be very thin, as application host technologies should always be easily replaceable.
At this point, assuming there are no significant gaps in the operations available between the two services, you can publish the new service's specifications to clients and begin plans to deprecate the old service. When you can deprecate it is more of a contractual issue than a technical issue. However long you've committed to maintaining it, that's how long clients will have a reasonable expectation to still use it.
If you really want to, you can even have the ASMX Service be a pass-through to the WebAPI Service, but in my personal experience that adds unnecessary layering to the whole setup and artificially complicates the abstraction of the business logic. Either way, the interface exposed by the ASMX Service wouldn't change.
The main thing here is the logical abstraction of the operations being exposed and the analysis of any gaps between what the ASMX Service can do and what the WebAPI Service can do. If that gets complex, then that's an indication that the business logic (and indeed the whole solution domain) is tightly coupled to the application technology being used, namely ASMX web services. That is the problem to be solved. Once solved, creating different application hosts and exposing different services which invoke the same underlying business operations becomes almost trivial.
You are right; you are stuck if you can't change the client and you want to change service protocols. Your client currently has a specific .asmx endpoint it is configured to point to and until you can update that endpoint and have the client stop using the proxy generated from the service, you can't change to Web API.
I'd still rewrite the service to use EF, though.
I was tasked at work to create a web application (viewable in Firefox on Linux!) that displays results in a tabular format using data exposed by a WCF service (written in C#) hosted on a separate Windows 7 machine on the same network. Rather than returning formatted HTML, the WCF service returns structs and it will be up to the client application to take these objects, pull out the data, and format it.
Unfortunately, it has been a couple years since I have worked with any sort of web technologies. What is the best approach to solve this problem? Is there anything more current than REST/AJAX/JSON/jQuery technologies? If anyone can point out some helpful and current resources on the proper way to accomplish this, it would be most appreciated.
Use a SOAP framework to consume the WCF service. Configure WCF to use SOAP (one of the HTTP-bindings).
Webservices are easy to consume these days thanks to a standard RPC format (SOAP) and libraries supporting it. You can surely find a SOAP client for any language you are proficient in.
Checking back in here to report my own solution for this problem. I ended up going a bit of a different route that produced the simplest solution for the situation. Instead of consuming any services on the Linux side, I simply made an ASP.NET website on the Windows/IIS side (where it is easy to consume the WCF services right from Visual Studio), and then just render the website on the Linux side via the URL in a Firefox browser. For me, that fulfilled the customer requirements and was perfect, although this may not be the best approach for others that need to work with or manipulate the data in some way.
im trying to perform a simple database insert from a submission on a SilverLight Webpage. Normally i would either use ADO or LINQ to SQL to perform this. You can not do this within a SilverLight Project, nor can you reference a project that can (a non SilverLight project). What would be the best way of doing this?
Thanks.
For the most part, Silverlight apps are designed to talk to web-based data services or databases via RIA services.
There are a a few approaches to your problem:
Reference a web service, like an .asmx or any REST servie
Use WCF to communicate to the backend
Use Silverlight RIA Services to talk to the database (it was designed to solve your problem)
Your best bet is to use the .NET RIA Services which will allow you to define server-side domain classes and due to the RIA Services link, will generate client side code in your silverlight project.
Another alternative if you don't want to use web services, is to Xml Serialization and Isolated Storage to store the files. You'd simply load the database into memory on startup, and then persist to the file when the apps closes, or periodically.
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.
Ok, all these methods of getting data in a Silverlight control are confusing me.
I've looked at ADO.Net Data Services, Web Service and Silverlight-enabled WCF services.
I'm just not sure when one is appropriate to use over another. What pros/cons do each offer?
I've built a web app, and a Silverlight control. I will be adding one of those 3 options to my web application and consuming it from my Silverlight component.
From the silverlight perspective, WCF is heavily constrained anyway, so most of the usual benefits of WCF don't apply. However, it is still a fairly nice, consistent programming model.
WCF is primarily a SOAP stack, so it is very good at presenting data as rigid operations. ADO.NET Data Services is a REST stack, and allows very expressive queries to be performed dynamically over the wire.
I don't know how it is in Silverlight, but a regular ADO.NET Data Services proxy (the bit on your client app) has very rich support for both query and data changes back to the server. Note that applying changes requires either a: Entity Framework, or b: lots of work. But you should get query and update very cheaply with this approach.
With WCF, you get a much more controlled stack, so you will need to code all the distinct operations you want to be able to do. But this also means you have a known attack surface etc; it is much harder to exploit a locked down API like a fixed SOAP endpoint.
Re regular web-services (pre-WCF): only go down that route if you want to support very specific legacy callers.
I know this is old, but I just wanted to add my 2 cents.
I would highly recommend using WCF; and use the WCF Service Library project over the Silverlight-enabled web service. They are both essentially the same, but the Silverlight-enabled web service changes the binding to basic instead of ws*. It also adds an asp.net compatibility mode attribute.
WCF is usually faster: See "A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies" # http://msdn.microsoft.com/en-us/library/bb310550.aspx
WCF encapsulates asmx, wse, msmq, enterprise services, and remoting.
WCF services can be included and run within iis, windows forms, etc.
WCF isn't restricted to using HTTP, but with minimal configuration can also use tcp, named pipes etc.
complex data types are easier to expose and serialize.
WCF just scales really well. Plus, they can be used to incorporate workflows from WF.
There's probably not a wrong technology to use, but it seems as if Microsoft is going to be moving forward with WCF. Plus, it's just so much easier to write one code base that can be exposed so many different ways with just a few configuration changes to the WCF service.
I recommend not using the Silverlight-enabled web service, just because the programming structure is set up a little better with the WCF model, but this is probably a matter of opinion.
If you have to choose between a web service and a WCF service, my advice is to go with WCF. It's more modern and more powerful technology. As for ADO.Net Data Services - you can use that if all you need is to retrieve/commit some data from/to a database back on the server.