Hi I have worked for a couple companies now. Both used MVC to create their software. One company used WCF Services for all of their Ajax Calls while my most recent company is making all of their Ajax calls to their Controllers. I prefer the WCF method as it seems to keep the code cleaner and more readable, however, according to MVC all view calls should go through a controller. I was just wondering if anyone had any good information, references, or articles as to which is better practice, or if it's better to make service calls to a controller or WCF service? Thanks
It looks both approaches will work fine. But, WCF is more appropriate solution if you want to have something like Service Layer inside of your solution. But for Ajax calls from the Web part to Controller work okay.
Related
This is more of a design question than a problem. So here's the scenario, you have an asp.net 5 application with a webapi controller and it provides data to many types of clients: web, ios, java apps, etc. Let's say that one of those clients happens to be an mvc controller within the same web host and visual studio solution as the webapi.
What are the ramifications of calling into the webapi as a class instance, instead of doing what the other client types are doing--which is to make a rest based network call? The obvious benefits are eliminating the over head of a network call and eliminating the serialization. But I wanted to know what some of the possible negatives could be. Has anyone done this before?
The easy solution could be that you could extract that logic to a separate assembly... let say a "Business Logic Layer" so that both WebApi and MVC could access it.
This has the downside, that you will not be able to have MVC and WebApi separate. I mean, using WebApi as a single data interface could allow you to host MVC app separately from where the WebApi is hosted... but the approach in the first paragraph will couple both proyects and will force you to host them together to have access to the data.
If you call the class directly any work done by the HTTP pipeline won't be done. So your API class won't have access to the HttpContext for example.
Also none of the security or Http related annotations (attributes) will work, so your MVC controller may need to deal with that.
I would like to expose the SQL Server Views via OData Web API but I don't want to create separate controllers for each views as there are too many of them and they will only accept GET verb for all the views.
I thought I can achieve this using BreezeController but it looks like I cannot as it is obsolete now (The package which has BreezeController attribute is marked as obsolete).
Is there any way to achieve this with OData Web API that works with BreezeJS?
The [BreezeController] attribute is not obsolete. In fact, it is central to the "happy path" Web API controllers you see in the Breeze samples. I wonder what lead you to think otherwise? What package are you using?
I'm referring to the ASP.NET Web API!
The ASP.NET Web API OData is a different matter. Despite "Web API" in the name, that is almost a completely different approach to server development with its own behaviors and wire format. It does not use the [BreezeController] attribute and never has.
I'm not sure what you meant by "view" in your phrase, "separate controllers for each view". I think you mean what I would call "type". For example, in OData you'd expect a "Product" endpoint for your Product entity type.
AFAIK, the Web API OData approach demands a separate controller per type. That's what Microsoft's Mike Wasson says in his tutorial. He writes ...
A controller is a class that handles HTTP requests. You create a separate controller for each entity set in your OData service.
BreezeJS supports Web API OData too ... although there are limitations imposed by the current Microsoft implementation that may give you pause.
We are working through these with the OData team and hope to have better news in the coming months.
I'm working on a web application that need to expose Json API for external apps and I'm planning to do an API centric architecture.
So basicly, the app will juste contains view/controllers for the web interface. the controllers will use Route::dispatch to create a request to the api part of the site (another controller in a package, but in the same laravel installation), then parse the result, and create view accordingly.
So I'm wondering what are the drawbacks, performance wise, of using this sort of architecture?
If each controller is writing the logic to internally dispatch another request then I'd consider abstracting that away from the controller and in to your own dispatcher. I doubt there would be a huge performance overhead. The application (as far as I know) doesn't get booted twice so you don't have to worry about that.
The only thing you need to be aware of is the input for the main request being used. Something you should take into account inside your dispatcher. Refer to this answer for more information.
You can also read more on consuming your own API.
So I can create a simple AJAX enabled WCF Service and consume it in Javascript in a basic WebForm as found in this example on MSDN (http://msdn.microsoft.com/en-us/library/bb924552.aspx).
Is it possible though to do this in ASP.NET MVC 3/4? The problem is there is no ScriptManager control obviously, which allows me to reference the service to be used in the javascript.
If it's not possible - how do I consume a WCF service inside javascript from ASP.NET MVC?
I cannot find any examples of this online either.. My google fu is off and I can't figure out what I'm missing here.
thanks!
Make sure that your WCF service works with JSON and then use JQuery to call the service. This might help: http://pranayamr.blogspot.com/2010/12/steps-to-call-wcf-service-using-jquery.html
I have a windows service that is supposed to send e-mails periodically.
Next to the windows service project there is an MVC 3 project that is sending e-mails with MvcMailer (beautifully).
I want to use the same engine to send e-mails for the windows service.
How should I do it?
Import the MVC binaries and create one controller and new views for this purpose? Will it work?
Saving it in the database and requesting my web project to send the e-mail might not be the best solution because the information is the result of a query and is too big to be sent in the request.
The only other option I see is to simply request the web project to do all the work but this way it wouldn't be beneficial to place the windows service in another service to save the site application resources.
How would you do it?
As an alternative to MVC Mail, ActionMailer.NET can now be used stand-alone outside of MVC.
The details are covered here
http://geeksharp.com/2011/07/06/actionmailer-0-6-released/
I would argue that calling a mvc mailer from the service might be an overkill. If the mvc project is supposed to expose sending the email API for all of your other solutions, then building a REST api might make sense. However, if you just want to bring the functionality of the action method to the windows service, then i would choose an in-process functional component. If you can refactor the logic of the mvcmailer action method into another assembly why not just do that and then include that assemlby as a depedency in your windows service solution.
If you can provide the over all purpose of the mailer and how it's used in the web scenario, it may help us to provide a better architecture.
Why do you think the query to send to mvcmailer us too large? If you have the mailer MVC project already working and exposed via a restful URL, that becomes your email service and simply call it as a web request from your service.
You can get around size constraints in your request That shouldnt be an issue.