Looking at the following diagram (which explains MVC), I see unidirectional data flow.
So why do we consider MVC to have bidirectional data flow while justifying Flux ?
Real and Pure MVC is unidirectional. It is clear from the the wikipedia diagram pasted in the question.
More than a decade ago, when server side frameworks like Apache Struts implemented a variant of MVC called Model View Presenter (MVP) pattern, they made every request go through controller and every response come back through controller. Everyone continued calling it MVC. Due to inherent nature of the web, any changes in the model cannot be propagated to the view without view sending a request or update. So Pure MVC is not implemented. Rather MVP is implemented.
Few years back, when frameworks like Angular, Ember, Knockout implemented MVC on front end, they implemented another variant of MVC called Model View ViewModel (MVVM) pattern, few folks continued called it MVC. (and few realized that terminology is not important and called it MVW (W stands for Whatever)), none of them implemented pure MVC.
When React was born, they took the opportunity to implement pure MVC (not MVP or MVVM), and renamed it as Flux with few changes. I feel Flux is one more variant of MVC. Although, Flux/React team says it is not MVC, I see lot of parity between both the architectures - Flux and MVC.
Because in Javascript frameworks the MVC does not work the way you depicted. The UI generally communicates bi-directionally with the model, as in:
User types into View input
MVC framework binds onchange() to update a model.
Ajax request brings in new model data.
MVC framework updates View input's value to match model.
In Flux architecture, the UI would only fire an independent action with type and associated data to a dispatcher which would then update the model the same way any background ajax method would update the model.
Reference:
http://www.thesoftwaresimpleton.com/blog/2013/03/23/client-side-mvc/
"Client Side MVC is completely different than Server Side MVC"
"We are setting up a two way communication between two objects..."
"In short we are wiring together the value of the firstName property
of the Person object to the value property of the input."
http://guides.emberjs.com/v1.10.0/object-model/bindings/
bindings in Ember.js can be used with any object, not just between
views and models.
I am an embedded developer and I use MVC pattern in my application. My application is very small and I have set up my architecture to be almost unidirectional MVC. But, I read this article, explaining client side MVC, and some thoughts about differences between MVC and FLUX.
Reference:
http://www.christianalfoni.com/articles/2015_08_02_Why-we-are-doing-MVC-and-FLUX-wrong
Traditional MVC
|------| request |------------| request |-------|
| | ---------> | | ---------> | |
| VIEW | response | | response | |
| | <--------- | | <--------- | |
|------| | | | |
| CONTROLLER | | MODEL |
|------| request | | request | |
| | ---------> | | ---------> | |
| VIEW | response | | response | |
| | <--------- | | <--------- | |
|------| |------------| |-------|
FLUX
COMPONENTS ACTION CREATORS STORES
|----------------------<<<<-------------------|
| |
|------| |------------| |-------|
| | request | | request | |
| VIEW | ---------> | | ---------> | MODEL |----
| | | | | | |
|------| | | |-------| |
| CONTROLLER | |
|------| | | |-------| |
| | request | | request | | |
| VIEW | ---------> | | ---------> | MODEL | |
| | | | | | |
|------| |------------| |-------| |
| | | |
| |--------------------<<<<-------------------| |
|----------------------<<<<----------------------------|
Some people adopted the term MVC to refer to JavaScript frameworks that others had pointed out were not pure MVC but were a variation that could be referred to as MVP (Backbone), MVVM (Angular 1) or more broadly MV* (also see Arun's answer).
When Facebook introduced Flux, they compared it to the issues with MVVM/MVP/MV*, but confusingly used the term MVC.
To pure MVC developers watching this video, Facebook's stated issues with MVC did not make sense, and Facebook's description of Flux was closer to MVC than the MVVM system they described:
The core problem is that they were "doing" MVC wrong. Then they fixed it, but decided to rebrand it and say they'd invented the pattern of decoupling data, view, and event handling
YouTube comment
Looks like your programmers created flux because they didn't know how to properly use MVC and event dispatchers.
YouTube comment
Related
I'm trying to understand how clean architecture works, last project i had a user, he can add a payment card and buy a subscription (example use case), but when it's new user, add and buy integrated as one step
Use case sample
According to what has been read, it should have two "Interactors", one "AddPayment" and "Purchase", , but... how can I mix:
The user can do both separately, but when he is new, in registration process he adds the payment method and makes the charge in one step,
I think I should have an "Add and pay" use case, but it would have repeated code and a broken paradigm, I see these options:
Make a third use case with repeated code
Merge from controller
Make a use case that calls the other two
How have you solved it?
I usually make a base use case that calls the other two. For this base use case I define a new request model that contains the request models of the others . The same applies for the response model. But sometime the request or response models have something in common and I create more condensed models.
I think that a base use case fits best to the include relationship of the use case uml model.
+-----------+
| AddAndPay |
+-----------+
| |
V V
+-----+ +-----+
| Add | | Pay |
+-----+ +-----+
The AddAndPay use case also handles failures of one of the use cases. E.g. if pay fails you might not want to add a payment card. Maybe you must invoke a RemovePaymentCard use case then or your transaction boundary is the AddAndPay use case.
I have added a timepicker to my datepicker. Everything works, but when I posts, the time will degrees by 2 hours (I think it somthing in moment js).
Does someone know this problem and know how to fix it?
The datetime that I inserted was 2018-10-09 09:00 to 2018-10-09-12:00.
Please check Application Timezone in your config/app file.
Example for me:
/*
|--------------------------------------------------------------------------
| Application Timezone
|--------------------------------------------------------------------------
|
| Here you may specify the default timezone for your application, which
| will be used by the PHP date and date-time functions. We have gone
| ahead and set this to a sensible default for you out of the box.
|
*/
'timezone' => 'Europe/Kiev',
Ok, I am trying really hard to love HATEOAS. Spring Boot with its REST repositories is amazing. Does everything I want. I just have two requirements that shouldn't be that uncommon. So how do I do the following:
Given I have the two following entities:
#Entity()
public class GameConsole{
#Id
private String name;
}
#Entity()
public Class Game{
#Id
private String name;
#ManyToOne
private GameConsole gameConsole;
}
Assume I have REST Repositories exposing the two entities.
1 - How do I generate a table list with the names of the games and the names of consoles with one request:
Request from GET - /games
Using whatever framework, jQuery, angular, doesn't matter, just populate the following:
| Game console | Game |
| PS4 | Uncharted |
| XBOX | HALO |
The problem is that when I query /games, I get a list of games with links to /games/halo/gameConsole, and not the actual ID of the gameConsole.
So does this means I have to loop and query each item to get the game console name?
2 - Drop down menu
Lets say I have a webpage to edit my Game. And I want to add a dropdown menu and put the updated game console.
To populate my drop down, I query /gameConsoles and get a list of consoles.
Again my problem here is that the id I get from the game is linking to the /game/halo/gameConsole which can't be matched to any of the items returned from /gameConsoles.
How do I solve that?
Really appreciate the patience guys in case the answer is simple.
In the context of Spring Data Rest you can work with projections - see here.
Using projections, you can embed your referenced objects rather than getting a link to the resource.
Let's say I want to build a calendar app (in HTML + JS) where the user can see one week at a time.
The user should be able to define events, e.g. Mondays from 1:00 - 3:00:
+---------+---------+ +---------+
| Monday | Tuesday | ... | Sunday |
+---------+---------+ +---------+
0:00 | | | | |
+---------+---------+ +---------+
1:00 /////////// | | |
//MyEvent//---------+ +---------+
2:00 /////////// | | |
+---------+---------+ +---------+
...
+---------+ ...
23:00 | | ...
+---------+
I thought about creating one model, EventModel and one view, EventView, and wiring them up by the usual MVC approach. An eventView would be rendered on top of the calendar grid as a separate layer, so it would be able to autonomously maintain its size and position.
EventModel has nothing but three attributes, startTime, duration and title.
Things become more difficult though, if the user defines an event that spans over midnight, like Mondays 23:00 - Tuesdays 2:00:
+---------+---------+ +---------+
| Monday | Tuesday | ... | Sunday |
+---------+---------+ +---------+
0:00 | /////////// | |
+---------//MyEvent// +---------+
1:00 | /////////// | |
+---------+---------+ +---------+
2:00 | | | | |
+---------+---------+ +---------+
...
+---------+ ...
23:00 //MyEvent// ...
+---------+
Now two views bound to the same model are needed.
Naturally, all changes in the model should be reflected in the view(s). Note that the number of views required for a single model may change (1 to 7) as the startTime or duration attributes are updated.
In other words: Changes in the model need to trigger instantiation/destruction of views for that model.
I see two possible approaches for achieving this:
Use some controller logic that dynamically generates/deletes the required number of views and models, and keeps the models in sync with each other
... which seems like a bad idea since that would require a lot of fumbling as well as an additional class of models.
or
Stick with one model and build a View proxy that acts like one view, but internally controls the required number of "subviews".
The second approach is much more appealing to me. I wrote some pseudo-code to illustrate it:
ViewProxy.onModelChange(model) {
if (model.hasChanged("startTime") or model.hasChanged("duration"))
this.destroySubviews()
subStartTimes[] = getSubStartTimes(model.startTime, model.duration)
subDurations[] = getSubDurations(model.startTime, model.duration)
subViews[] = this.buildSubviews(subStartTimes, subDurations)
subViews.bind(model, "title")
endif
}
The downside with this is that the subviews unnecessarily get destroyed and re-built on all model updates (except title only), unless I include additional logic - which is not so trivial. Also, this proxy is some weird thing between controller and view, which somehow makes me feel uncomfortable.
So my question is: Is there a standard approach to this problem? If not, which issues may arise with the above solution? Any other solutions?
Your EventModel maps to multiple View elements because your model contains multiple sub elements (EventDayModel).
Sure, the input definition of the EventModel might be title, startDateTime, duration, but the model conceptually consists of one or more EventDayModel elements (each containing a startTime and duration).
So instead of maintaining a one to one mapping between the EventModel and the EventViewProxy (which effectively controls the view elements corresponding to each day), why not just subdivide the EventModel into a list of EventDayModel, each which have a one to one mapping to EventDayView elements.
When you change an EventModel, it's EventDayModel list is recalculated and the corresponding EventDayView elements are updated.
After searching around for a while, I found that the answer is The Composite Pattern.
So, the idea is to treat all the event view snippets of one events as a single view that manages several subviews.
As for data binding, I guess this is not possible without a bit of logic in the view. In my case, I decided that the view itself would be composed (think Composite pattern!) of a smaller MVC hierarchy. So the models inside the view are bound to the subviews by simple data binding, and the ViewProxy manages updates in the underlying model.
You could emulate Google Calendar structure which re-renders the calendar rather than destroying and recreating subviews.
If you use Angular then you could tie up scope variables and put a watch on the model attributes to update the view properties.
Each view could be seen as "div box" positioned depending on the start and end times. If the user deletes the event then the associated "div box" and the event object is removed from list of events.
If there is an update with to event then we update the coordinates of the "div box" depending start and endtimes.
The resource below is to show the model structure used by google calendar.
https://developers.google.com/resources/api-libraries/documentation/calendar/v3/java/latest/com/google/api/services/calendar/model/package-summary.html
Does anyone know its its possible to define a table once in a .feature file & then access it from multiple scenarios? I'm not chaining scenarios but many of them do need to pass tables with the same data to their step definitions - also for this reason examples won't really do what I need here.
Thanks!
One possible solution is to tag all your scenarious where you need a table:
#given_have_table
Scenario: test
Then I am happy
Then bind Before hook to this tag and call step that declares your table from within Before hook definition:
Before("#given_have_table") do
steps Q%{
Given I have the following table:
| a | b |
| 1 | 2 |
}
end
Alternative approach is to construct required table in tagged Before hook without calling step:
Before("#given_have_table") do
#tbl = { :a => 1, :b => 2 }
end