Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
As I am trying to describe a system I built in a research paper, I came across the following notational problem when trying to represent the complexity of the system I created:
Assume I engineer service A, communicating with the world solely through its RESTful endpoints. Then, I engineer service B, that uses service A as its backbone and represents its data to the external world.
Assume that service A has its own models and data controllers. Should then the RESTful endpoints be conceptualized as views in the MVC pattern?
Assume that service B has its own set of proxy models that map more or less directly models of service A. It provides a set of GUI views to the users, with a completely separate set of controllers. Where does service A come in the MVC? Should it be represented as an encapsulated model?
Real world example (not related to the problem I am working on) would be:
del.icio.us and pinboard.in provide roughly akin set of APIs, and thus can be swapped as a service A for service clients (for the purposes of question assume they are both built upon MVC pattern, but may have completely different sets of models and controllers)
Delibar is an iOS app, and thus follows the MVC schema and matches requirements for service B; assume Delibar models its data after the data models of service A as represented in the API endpoints.
Are thus pinboard.in and del.icio.us the model for Delibar? Are RESTful endpoints the views? And are thus the view sets for pinboard.in and del.icio.us the same?
Endpoints are actions/operations on the Controller. Views are the data (HTML, XML, JSON, or otherwise) returned by the controller in response to an HTTP GET request.
Service A is not represented as part of the MVC triad of Service B, since MVC deals with the Interactions against the Model and selection of Views by a controller. Service A is accessed though the Data Access layer of Service B. If you are using an "Active Record" pattern, then queries or changes to the Model by the Controller in Service B will be passed through to the data access layer by the Model itself. If you are using a Domain Service / Data Mapper / Repository pattern, the controller will call out to this layer which encapsulates Data Access.
Related
Slowly but surely I adopt microservices approach. So I created some microservices always returning json.
But now I was thinking to convert a monolith into microservies. I noticed every endpoint returns a html page, namely a string interpreted by Thymeleaf as a html page.
So how can I transform that to microservice ? Should the service still return this html page ?
Microservices Architecture is an architectural style that structures an application as a collection of services. In other words, it's something like separating the big system we have into subsystems that connecting and calling each other.
So, each microservice has system internal calls (microservice calls another one) and external system calls (call from a user through his web browser). Microservices call each other using APIs. But when it comes to the external calls, it might respond with a JSON or HTML as you like as any normal system.
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.
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
we are working on a restful system. On the front-end side we use angular js and on the back-end side spring. Now one of the question is: how ensure that the exchanged object on the two side on the time remain consistent. I don't mean the realtime exchange of data that are persisted on DB, I mean the consistency of the programming objects.
Example: front-end sends a user objects with the fields: firstname and lastname, and the backend takes this object user with firstname and lastname.
In the future it can be that a field must change his meaning: for example firstname becomes name. Now the front-end can't speak with the backend.
The best way to cover this is to write integration test: from front-end to DB. But is there not a better way to test only this "exchange-layer"?
One idea that i had is to put this objects (java class for backend and angular file) in a separate library, and make some control on the equals of the fields. But is this the best way to do that? Any idea how make this better?
For this case if you´re using Spring and modelAndAttribute, as soon as you changes one of the side client/server and an entity attribute name you will receive a BindingResult Exception from the framework. The only way to test this is by integration tests with selenium. Which will made the whole client/server transaction in the test to check that everything still working properly without any exception.
Read the documentation of how to integrated with Spring MVC https://spring.io/blog/2014/03/26/spring-mvc-test-with-webdriver
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.