The common tasks of web application framework(ex: Django or Laravel or .NET or beego):
request / response abstraction
session state
user authentication & authorisation
page templating
URL mapping
DB access
security
caching
MVC design pattern implement above common tasks, as shown below:
URL mapping is handled by Controller component of MVC. Controller routes requests to handlers. Ex: http.ServeMux is the controller from GOLang package
request / response abstraction is performed by Controller by registering the handlers, written by web developer, as shown below:
sm := http.NewServeMux() // in GoLang
sm.Handle("/", productHandler)
session state is handled by the handler code written by web developer
Page templating is handled by templating engine(view component) of MVC
user authentication & authorisation is handled by the handler code written by web developer
DB access is handled by model component of MVC.
security and caching is handled by handler code written by web developer
Is this the right understanding on MVC design pattern to implement common tasks of web application framework?
There are many definitions of the MVC pattern. It was evolving over time and it was used differently in different frameworks and contexts.
When it was invented, there was no HTTP protocol and the request/response part wasn't present. There were some other ways in which the user request was handled. With time, new template engines were invented and HTTP becomes dominant protocol on the web.
MVC is considered to be a pure presentation pattern since it mainly orchestrates views and model(whatever model is representing). Also, one of the main reasons why MVC is invented is separation of concern. It is important to keep it clean, short and to let other layers take care of logic.
The common task of the web application framework is to serve as IoC container (Inversion of control) and let its component worry about specific responsibilities. So if it is a web framework, it will probably have session, cookie, MVC... components.
Controller methods are just an implementation of HTTP interface. URL Mapping can be considered as an argument to controller method.
Request/response are handled by web component (servlet in Java)
Session state is handled by session component and can be configured by developer e.g. session expire time or session cookie type or even session type (database, in memory)
Correct
Usually, there is a proven auth component in the framework, but it can be written manually (not recommended)
DB access is handled by a persistence layer like JDBC in Java. Model in MVC is responsible for data that should be presented on the screen or submitted by the user.
Same as 5
Related
I've one missing link to understood how it could work to "connect" my EF core's DbContext to different applications in following scenario:
I've got one application project which contains the whole EF Core Code first datamodel (Entities, Business Logic, Enums etc).
Until now we're using a WebAPI application to share data with multiple endpoints.
So the data we're exchanging now are quite static at the moment. We create our DbContext and the API is using it for data reading and write operations.
Now there is customer request to also build a WebUI (Blazor). So we still want to use the WebAPI for data exchange in the UI, but further we need some more business logic elements from our data model (containing INotifyPropertyChanged event handling etc). We implemented the event handles in the entity classes. So we intend to build a session object for each user/client which contains the DbContext instance. But how can handover an instantiated DbContext from the Web API to my UI Application.
Would be nice to get some input. Thx for any advice.
You do not pass the DBContext object to "UI Application", such as a Blazor app.
You did not mention what flavor of Blazor you are using... However, the following may be applicable for both Blazor Server App and Blazor WebAssembly App... From what I've gather from your question you are exposing Web Api end points to retrieve data and save data. This is good. What is left for you to do is to create code in your Blazor that access those end points. You should use the HttpClient service to do this. If you use Blazor client side, this object is configured and made available for injection in your components and services. This type of HttpClient is based on the JavaScript Fetch Api.
If you are going to create a Balzor Server App, then you'll have to add the HttpClient service to the DI container and configure it accordingly, and only then you'd be able to inject it into your components and services. In this case you should use the IHttpClientFactory to provide the HttpClien onjects.
In principle, you have to query your Web Api methods via HttpClient.
Note that if you use Blazor Server App, you don't have to use Web Api. Instead you can create services that perform similar functionality to that provided by the Web Api.
Please, go to the docs and acquaint yourself how to use the HttpClient with Blazor apps.
Hope this helps...
I understand that a HTTP session is the idea to associate a state of a web application for different users which is done outside the protocol in software as HTTP is stateless.
I didn't notice before today that some articles and manuals in the Spring universe are talking about a web session as well. They make a connection to reactive webapps and streams, however I don't find anything on https://www.reactive-streams.org/ and the reactive manifesto and am thus uncertain that it's a reactive thing.
Since it's differentiated it has to be a thing, but is it a concrete technical concept or just another word for HTTP session? Does it exist outside of the Spring universe?
HttpSession comes from the Java EE servlet specification and is defined as:
[...] a way to identify a user across more than one page request or visit to a Web site and to store information about that user.
A WebSession is essentially the same thing but is used in the context of the Spring WebFlux which provides reactive programming support for web applications.
Note also the existence of the Spring Session project providing transparent integration with these different kind of sessions.
I am creating an application which has a front end developped using Angular, and a backend developped using SpringBoot.
The problem is that the backend has controllers with request mappings and models (services and repositories) and no views , so does it really implement the MVC pattern?
I have read in this article " Spring MVC or Spring Boot" that spring MVC which itslef implements the MVC pattern is a part of spring boot, so basically spring boot is MVC, which is true when you have views and HTML pages in your project, but in my case i can't talk about views since i am sending and recieving JSON data from a restful API.
According to https://www.wikiwand.com/en/Model%E2%80%93view%E2%80%93controller
view means presentation of the model in a particular format.
I think it is good definition. Particular format in case of backend for REST API happen to be JSON or XML.
From the same page
Some web MVC frameworks take a thin client approach that places almost
the entire model, view and controller logic on the server. In this
approach, the client sends either hyperlink requests or form
submissions to the controller and then receives a complete and updated
web page (or other document) from the view; the model exists entirely
on the server.
In your case the View would be the front-end. The View is the presentation of the data in a human understandable way.
So I believe the View in your case would be the front-end app.
SETUP
At present I have a controller heavy spring MVC application. Its components are heavily guarded with spring security. Most of the datamodel fetching, form binding etc... is done within controllers.
I however see great value addition in using spring web flow.
However I would like to use web flow in a specific way.
First of all I would like the web flow to be like traffic police directing web requests to appropriate controllers inside every state (Along with form binding objects, request, session params etc...).
I would like the controller to ultimately determine direction of web flow like successful login or goto registration page. However it is web flow that will consume the decision and facilitate the transition to the next state.
This next state will in turn leverage mvc by invoking appropriate controllers.
This way spring web flow is just like a facilitator and does not contain too much decision making logic & business logic invocation calls.
This is important for me since controllers can get heavy with respect to services it invokes and can potentially invoke them in a multi-threaded approach. All this cannot be done in spring web flow definitions
QUESTION
My question is very simple and basic. Is Spring Web Flow designed to perform like this on top of Spring MVC?
Is it possible to designate just this traffic regulation and state flow functionality to web flow while preserving most of the control and service invocation logic inside the controller?
--Am I understanding anything wrong here? I want to get these questions cleared before
embarking along this path.
This may be a little late for you, but I'm not sure webflow will give you exactly what you want to achieve. You want a router, and that's not really what webflow was designed for. Webflow is used more for multi-page form type flows, and using it for much more risks running into the limitations of the framework. Webflow cannot be used to intercept all web requests -- only those initiated through the flow mechanism, and it has very strong opinions on what state transition is (for example, form/bean validation is the default, although it can be overridden if required).
It's not that it can't be used as a router, it's just that it's not designed for this so you're likely to find impedance from its form based design goals.
I have a Spring MVC application that uses Spring Security to handle user login authentication, which works fine.
Now I want to add some Ember.js and Angular.js code to the HTML pages that accesses the Spring RESTful web services (which just return JSON data).
How do I bind the user login authentication to the authentication for the RESTful web services? In other words, I want to make it so that the RESTful web services can only be accessed once a user has logged in. That way, the Angular.js and Ember.js libraries can access these RESTful web services securely from my user pages only without anyone else being able to directly call them.
I read on one other post that Spring Security was never meant to be used with a full Ajax framework, is that true? I hope this is not the case. I'd imagine that this type of thing must be pretty common now as there are so many AJAX client side frameworks that work based off accessing a JSON/RESTful API.
It is certainly not true that Spring Security was never meant to be or cannot be used in AJAX applications. I have two applications in production that use Spring Security as well as AJAX and more applications under development with the same mix.
If you are going to use EmberJS or AngularJS in an existing web application with Spring Security working, you should not face too many problems if you simply add the JavaScript library to your project. This is because once your users are authenticated, any normal HTTP requests will be treated as authenticated as well because the browser will ensure that session information is passed back and forth using cookies or URL parameters, as appropriate. You can see one of my working examples on Github for Spring Security and EmberJS integration.
The only thing you may need to worry about is CSRF tokens for form submissions using AJAX. The latest Spring Security documentation has a small section dedicated to this so you should not face too many problems getting that to work either. However, I would like to clarify that this particular issue is not specific to Spring Security. CSRF protection typically involves including a secure, randomly generated token with every HTTP POST request. The challenge arises from making existing JavaScript libraries aware of this token and how it should be included in HTTP POST requests. This would be a challenge in any application, not just those using Spring Security.
If however you will work with stateless clients, such as, mobile devices, you will be unable to rely on the default Spring Security mechanism of storing the user credentials in HTTP Session because HTTP requests will not have information to tie them to a session. This again is not specific to a Spring or Spring Security application because the constraint is imposed by the nature of the client and the client-server communication rather than any server-side technology. In such circumstances you will need to pass some authentication token in the HTTP headers for the application to maintain security state on the server side. I have a working example for this as well. If you need more details, there are articles on the web that explain how to do something like this with Spring Security.