I use Silverlight 3 with ASP.NET MVC. For database operations I query SQL Server database using FOR XML, and send the data as XML over wire to Silverlight client where it is deserialized to business object. Is this approach good? I do not find much resource on Internet about using Silverlight, ASP.NET and XML together.
Why not use a SOA approach? I'll first tell you my approach then a link under that for a direct ASP.NET MVC approach. My approach is only because I need to expose a web service to other devices.
I have a WCF library which acts as the DAL and some Business Logic. I then have my asp.net reference this dll. Nothing in the Model's folder. So the ASP.NET works the same.
For the silverlight, I use a service reference to the wcf service. Some features which uses the same data as the asp.net does, calls into the ASP.NET controller that is specified as how Tim Huer did it here.
Related
I am using asp.net for development that uses both web forms and mvc.
I have some code in in an application that produces a downloadable excel file. If there are any validation issues, it shows issues in why the program cannot produce the excel file.
My question is what is the best way to create this code so that it is shared between multiple C# applications that use either MVC or Web Forms. I am new to web services to thinking of using that but I understand there is WCF and also MS Web APIs. Just looking for some suggestions. As mentioned, the code will either produce a downloadable excel file or show validation errors on why it could not produce it due to data issues.
actually there is no such thing as best way. you can use asmx, wcf or web api. its completely up to you.
if you use asmx you can only write a soap web services.
if you use web API you only have restful.
but with wcf you have both soap and restful.
here you can read more about .net web services technology:
WCF vs ASP.NET Web API
Cenario
Website: ASP.Net MVC 5 managing models, controllers and views.
Api: RESTful Web api managing models, controllers and returning JSON
The problem: Code duplication in BL. We are always redoing the same logic in both places.
The approach I have in mind:
Take the BL out of the Website MVC and keep it only in Web Api in a separated VS solution
The Website now is a consumer of Web Api
About the content negotiation, I think in two options:
Web Api "knows" which format to return (ViewResult, JSON or XML) and serialize/deserialize in BL depending of who is requesting (website, mobile apps, etc.). The advantage I see is to keep taking
advantage of strongly typed model to render a view in Website
Web Api always return JSON and the consumer app handle result in client
Questions:
Is this approach a good practise?
Which is better: Web Api always returning JSON or a smart Web Api who "knows" which format to return?
Like #David said, you don't really need to consume web services in your MVC controllers. You could just design it in such a way that your MVC and API layers are just another "view" to your Business layer. So, in case you are thinking in a terms of your visual studio solution, your might have a Data layer project, a Business layer project and 2 front end projects MVC and API.
I have a legacy ASP.Net web application that is basically used to process web services.
I am adding some new functionality and would like to start using EF4.1. I'm fairly new to EF, and I'm not quite sure the correct path to take here.
The client using this web service is a Linux based client running Apache, so data will be passed back and forth using SOAP.
My question is, what is the best practice for getting EF models into and out of a SOAP data class? Would using EF POCO classes be the best for this?
You could use the Entity Framework for data access with either a ASMX or WCF web service that will use SOAP.
Using Entities with Web show give you some direction and ideas.
I have an existing Asp.Net MVC Website and I would also like to provide a Web Service from the same domain.
What is the best way to approach creating a web service in this scenerio?
Do I add to this project or...?
You should be able to add an WebService file directly to the MVC project.
Right click on solution and select add new item, then select the web category and att the bottom of the list there should be Web Service.
Just remember to check that the routes does not eat up the call to the webservice.
That way the webservice can get access to the same model classes as the MVC application.
You can add a web service to the project just as you do in regular ASP.NET web apps, however, MVC basically IS a web service. You could create a controller that handles all the requests that you want your web service to handle.
With the advent of MVC it is quite common to do applications that only ever load a view once, then use AJAX and client scripting almost the entire rest of the life of the application. Your AJAX calls just hit up action methods for their goods and then use the deliciousness that is JSON to parse the data and utilize it.
In my opinion designing a web service as a controller instead of using [WebMethods] is far simpler and a lot more fun!
First, the question is "what do we mean by web service?" This can mean anything from a MVC page that responds using XML, JSON or some other agreed upon format to full blown SOAP and WS-* encumbered nightmares.
Anyhow, perhaps the best place to start is the WCF restful services -- these play very nicely with MVC, including routing.
The cool kids are using openrasta.
I have just experimented my first ajax enabled WCF service in a sample asp.net webform application... If i have 10-15 pages in my webapplication which involves add,edit,view and delete operations, is it possible to make them ajax post and get without using .cs(codebehind) of all pages...
What are the pros and cons when choosing ajax enabled WCF service in an asp.net webform application?
At first, if you want to implement the server side of jQuery Ajax calls, you can do this with either ASMX or WCF services. You can find a short comparison between these two here. WCF is more modern technology and will be my preferred choice for new projects. It can provide you with the following:
Help you program against an interface
It will serialize/deserialize objects to JSON for you. No need for JSON libraries
Provides client methods that you can use (via the ScriptManager). It is also easy to use jQuery if you prefer
As an disadvantage I would say that it will take you some time to learn the technology. I found that proper configuration of web.config was a little tricky.
I usually have a single svc service that serves all Ajax requests. You can implement as many methods as you want in a single service. The services are called from different pages.