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.
Related
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 looking for suggestions regarding methods of hosting a 'custom STS' within a self-hosted OWIN pipeline.
It seems that the current documentation on custom claims providers has changed very little in the few years since I created a custom-STS with WIF 3.5, and I'd like to bring the implementation up-to-date for use with ADFS 3.1 (Windows Server 2012 R2).
I'm aware that the SecurityTokenService has moved to the System.IdentityModel namespace in 4.5, and ideally I'd like to encapsulate an STS within an OWIN-self hosted WebAPI, but I would be happy to use something like Nancy instead if necessary (since MVC does not appear to run in OWIN owing to it's reliance on System.Web), but I am struggling to find a way to utilise my implementation of SecurityTokenService from my WebAPI's DelegatingHandler since the wrapper functions in System.IdentityModel.Service.FederatedPassiveSecurityTokenServiceOperations also appear to be reliant on System.web, and hence IIS.
I plan on presenting the required input form elements to the user by manually crafting the response stream and parsing the POST - I realise this is a terrible idea compared to using ASP.Net or MVC, but at this stage this is really just a proof of concept for me, I'll be letting ADFS handle the cookies, since this will just be registered as a custom claims provider.
Should I drop the SecurityTokenService class in favour of a better token-generation implementation, or should I drop the wrapper class and manage requests to the STS manually using the IOwinContext's Request and Response objects, but if so, how?
Many thanks
I'm trying to learn web development.
I understand (mostly) the concept of MVC, but I'm confused about why an MVC model is used on the server side...like Spring MVC. Isn't the server side the Model and Services, and then the client side Services, View, and Controller (AngularJS even makes that pattern explicit on the client side)?
I'm really struggling with how the MVC model fits into or facilitates server-side development.
MVC is a pattern used by much more than just web applications. Any app with a UI could use an MVC pattern.
The idea is that you have a View (html, or a window in your OS, or even a report or something), and you have a model that represents the dynamic parts of that view. Then you have a controller that is dedicated to processing input and doing the "business logic" to generate the model and apply it to the view.
So.. for example on the Server you might have this MVC pattern:
A controller receives the HTTP request and processes it.
It builds a model
The model is applied to a view to generate HTML and send it back as a response.
On the client it will be similar (but a bit different in Angular's case):
A controller is used to determine and manipulate the model.
The model is then bound to your view via directives. (Angular is really more of an MVVM pattern, but it's similar enough)
The view is similarly bound to your model via directives. (this is where the MVVM part comes in).
The idea here is that both the model and the view are kept up to date by directives.
The controller just contains "business logic" for manipulating the model.
Clear as mud?
No worries. Just know this: It's just a common pattern. It's not "server specific" or "client specific". It can be used anywhere by anything requiring data to be scrubbed into templated output.
EDIT: More thoughts.
In the case of a Web API that serves up JSON (or even XML) on the server, you're still using MVC in most cases. This is because what you're doing is:
Process the request in a controller.
Build up the model in the controller.
Render the model to a "view", which in this case is a view that serializes it out as JSON.
In the good ol' days of yore, the client side was only a display. The server was responsible for communicating with the model, applying business logic, generating a view, and sending the static, rendered content back to the client (browser).
As the web matured, some of those responsibilities migrated from the server to the client. Now, the server-side is often a thin layer like RESTful API that stores the "official" business logic (rather than convenience logic on the client) and stores the model. But for performance and user experience, the client now stores a copy of the model in its own model layer, communicating with the server and/or local storage as necessary, and having its own controllers and view logic to provide an awesome user experience.
So does MVC still apply on the server? Yes! It's just different. The server often generates the initial view from which the client-side application runs (taking localization or internationalization into account, for instance) and still houses the official model. But more importantly, the "view" in MVC just changed. Instead of the server-side view being HTML, it's now JSON or XML that the client application consumes instead of just renders.
So for functionality's sake, we still use MVC on the server. But for an awesome user experience, we use MVC on the client-side now too.
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.
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.