To which part of the MVC pattern belongs an API? Am I right with the assumption that it belongs to the view?
I'm talking about an application which provides an API to access data from the model.
Then these are conceptually different things. You are offering an API on your server (let's assume REST based); the API here is your server and the software which runs on it. That software may internally be built using an MVC pattern. An API request is handled by a controller, a model, and the response is output by the view. An API request uses all three parts of MVC. "The API" is what your software looks like "from outside".
If you consider the server you are connecting to through the API as a data storage, the API is a layer between the data storage and the controller/view.
In MVC architecture, the model contains a data storage with a service that controller or view can access to obtain the data.
In this case, API is the service, so I would say it is part of the model.
Related
I am to start designing & architecting a fairly big database business application (data entry, notifications, reporting, data export and usual security restrictions for data). Multiple clients - mobile apps & multiple websites will be there. Plan to use Asp.net MVC5 & Sql server for the development. Phonegap will be used to create mobile apps.
I plan to create an API. All interactions to the Database will be through the API (a REST API). This REST API will be created using Asp.Net MVC5. The front end will be developed as an HTML5 App which calls this API using AJAX. All interactions with the API will be through AJAX calls. Need to expose some of these services (5%) to third parties also.
For e.g. for a supplier management feature, there will be services like SupplierAdd, SupplierEdit, SupplierDelete, SupplierList etc. in the API. HTML5 App will call them through AJAX and do required. Necessary security will be imposed for these services using a login and token based security system.
Plan to use some Javascript frameworks like Angular JS for front end.
The entire application is one with around 200 DB tables and lot of relationships between DB tables. Business logic is only moderately complex. This is mainly a data storage & reporting application.
Is there any problem with this full API based approach ?
Another approach suggested is to avoid AJAX and Javascript and use ASP.Net MVC itself. No separate API will be there for each operation. .cshtml will submit to the controller method and this method will call the Business Layer and do operation. Services which are needed for mobile apps and third parties alone are exposed as API. Is this a better solution ?
The issue which I see for the second approach is that when more and more mobile applications or websites come in future, it does not offer needed flexibility. Also, exposure of some of the services to third parties will be difficult.
I request experienced architects to comment.
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 have a Typical SOA web application which has the following components as expected.
The Web Client - Sprinv MVC
SOAP Services - Spring
The Reference Data is centralized which is exposed thru its own SOAP Services.
The SOAP webservice responses have codes for elements(like CountryCode, CityCode etc).
I need the suggestions as to what should be the best approach to for ex display the Country Description instead of the country code (which needs another SOAP call to reference data and same with other codes) on the web page ?
Few options are like:
Write a custom tag library which would do the necessary calls and get the data.
Fetch all the ReferenceData descriptions and put it into some kind of HashMap, add it to the model to be consumed by the web page.
Any other better ways please advice.
Since it's reference data, no one expect it to change very often, right? Retrieve them once and serve them up using #ModelAttribute. See here.
Spring MVC is still server side, so it can handle very large data e.g. all the street addresses in US. You simply need to make sure you add some sort of filter if you don't want to serve the entire collection. And simply partial update these reference data with the latest on regular basis.
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.
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.