Ok! But where do you draw this line? And why?
Many MVVM Experts - whatever makes them experts - would tell you: Delphi is unable to do "real" MVVM because we have not the binding stuff like C#.
And no! We don't compare the live binding with C#'s binding.
So why I'm still on this project since 2015, to prove the experts wrong? No...
The reason why I'm still developing an MVVM-Framework is that I'm looking for the best way - with Delphi - to separate the form from the business logic and the database.
Perhaps, in the end, we will have some kind of patter that should not be named MVVM, but I don't care if it works as expected. Comparisons with C# should be stopped here immediately. We do not edit XML files by hand and we like to avoid so much typing for every propertychange. :-)
Transferring data from an Edit to a property in the ViewModel, to the Model, to the database is a piece of cake. But even at this point, I do not want to fire an event like "Hey my Name has changed guess what the new value is, or ask me". So I like to broadcast my Name to all listeners!
But when it comes to ListViews or Grids, things getting difficult. What event should I fire or what if the Grid is scrolled, should I preload more rows? Is this part of the binding or the ViewModel or a Cache-Class? Where to store the data?
But back to the topic!
MVVM did not have access to a component, MVVM is only dealing with properties. MVC/MVP has more direct access. So what can we do to get "kind of" access but not the component itself? If I cross this line, will every expert tear me up in the air? So I do not do this.
Of course, you can do some kind of imposer grid that is able to handle a properychanged event and then? Get the complete data to compare or just refresh all data in the grid? Because one "cell" has changed? No sorry, not on my shift.
The View has - perhaps - some stuff to do with the grid. But not holding the data! That's why I like the FMX, TGrid implementation where you have to provide the Data to the Grid only for the cells that are currently displayed. But how can you connect the Grid to the ViewModel, I mean how could the ViewModel throw some events to do so?
Your GridViewModel could have a property Cell[Row,Cell : Integer] : TValue; But I dislike to have a ViewModel for every Grid!
Your GridViewModel could have a property Cell[Row,Cell : Integer] : TValue; But I dislike to have a ViewModel for every Grid!
Imagine this kind of application:
One Form as Person.View für editing all the Person-Data fields. But at the bottom a nice grid with matching addresses. If you click on the Grid the data is loaded into Edits.
One Form as Person.View für editing all the Person-Data fields. But at the bottom a nice grid with matching addresses. If you click on the Grid the data is loaded into Edits.
So wouldn't it be nice to have some access/datastore in your Person ViewModel for the grid also?
I think so... I call it GridProperty and in this case I call it:
fMatchingAddresses : TGridProperty;
fMatchingAddresses : TGridProperty;
On the View I have a normal TGrid, but how to connect to the
Property MatchingAddresses : TGridProperty;?
Just place a TGridAdapter from the MVVM tab on your form and connect your Grid to the GridAdapter. DONE. Everything else is done behind the scenes. You can configure the GridAdapter like the were a database involved, to select the Fields you want from the all-possible-field-list.
Property MatchingAddresses : TGridProperty;?
Just place a TGridAdapter from the MVVM tab on your form and connect your Grid to the GridAdapter. DONE. Everything else is done behind the scenes. You can configure the GridAdapter like the were a database involved, to select the Fields you want from the all-possible-field-list.
I call this a #PropertyChangedTunnel. Is this already not MVVM anymore? Whatever! Then find a better name for my pattern and I will consider changing the framework name... ( Perhaps not )
And there will be some kind of ORM interface stuff to fill the property with the necessary data from the model and/or give a callback to read more data from the Model/Database.
And there will be some kind of ORM interface stuff to fill the property with the necessary data from the model and/or give a callback to read more data from the Model/Database.
Does it work?
#FastAsHell
Stay tuned... More info's are in the pipeline.
There is a pretty significant difference between MVC, MVP and MVVM - the way these pieces know and interact with each other.
ReplyDeleteIn MVP the view knows the presenter and and the presenter knows the view and they send events and data to each other.
While MVVM is very similar these two components (view and viewmodel) typically don't know of each other - and the solution how to connect them is via whatever kind of databinding.
The viewmodel represents most aspects of UI like enabled states of specific elements and such (thus its name) and their interaction so it can be tested without needing a UI or mocking the opposite part like in MVP.