CodeRage 7 - Malcolm Groves - An Introduction to Model-View-View Model (MVVM) in Delphi

hello I'm Malcolm groves and in this session I want to give you an introduction to mvvm model view viewmodel in Delfy here's the rough agenda we're going to talk about the problem we're trying to solve and a couple of different approaches to solving it then drill into model view viewmodel and talk about the component pieces we'll walk through an example a simple example application and look at some common problems that you strike talk about a few more things to think about when you're starting down this mvvm path and then look at some more resources broadly speaking if you break up to the logic inside an application you can put them in the three buckets your presentation logic in terms of what your form is doing and what controls are presented to the user at any particular time your domain logic the the the logic of the actual problem domain you're trying to solve and also your data access logic how you talk to the database how you save things how you load things where you put all of this logic in your application and how you separate all of this logic from each other in an application matters an awful lot and a lot of effort and time has been put into this over the years and to how you break an application down into these different areas if you think about the traditional Delfy approach to this for one of a better word I couldn't think what to call this approach the rad approach to this these three areas of logic tend to end up mixed together in a lot of cases they don't have to but they often do your data access logic might be mostly separated off into data modules but some of it leaks out into your forms in datasource events and those sorts of things presentation logic tends to be mostly in your form domain logic tends to be spread across both of those places but most importantly they tend to be mixed together so a single event handler for example might deal with some presentation logic meet some domain logic decisions all wrapped up in in in you know adjacent lines of code this has some advantages of course applications like this that take this approach tend to be quick to develop that's the whole point of RAD rapid application development so you can start building things quickly but what tends to happen unless you're very careful is that that speed of development tends to slow down the the bigger the application becomes but another advantage of this approach is that it tends to be well understood if you hire a Delfy developer off the street chances are they understand this approach to building applications some definite disadvantages though it fairly quickly becomes hard to maintain and brittle changing some aspect of your presentation logic impacts on changes in your domain logic for example it's definitely hard to test because your domain logic is all mixed in with your presentation logic it's hard to unit test that domain logic because you cannot isolate it and it's definitely what's becoming more and more of an issue now since Delfy has gone cross-platform is it's hard to replace one UI with another without having to rewrite a lot of that presentation logic and domain logic because they're all mixed in together so if you want to slide your windows UI off your presentation logic and replace it with an OS 10 UI or a with mobile studio with a mobile UI that becomes hard and in some cases it becomes a case of rewriting so this is not a new problem things like MVC Model View controller which you might have heard about more recently from the web world or from Objective C in the Xcode world has you know there's got a lot of attention there's a thing called model-view-presenter which was a pattern that came up trying to deal with some of the perceived problems in MVC mvvm intern was another pattern and the one we're going to talk about today which evolved to try and leverage some more modern UI capabilities like data binding the core thing about mvvm is that it focuses on the presentation layer mvvm has nothing to say about the data access layer and it has very little to say about your domain layer even though model appears in the name it's got very little to say about how you should build your model it very much focuses on the presentation layer the blue arrows here indicate who knows about what dependencies if you want to say so your model knows about nothing except your model your view models know about the model and and other view models but they know nothing about the views the actual forms in your application in terms of the forms tend to know about everything I'm so that there's a nice clean separation you can change your views and it doesn't impact your model and it doesn't impact your view models because neither of those know about your views and as I mentioned or internet before live bindings is used to tie your views to your view models let's talk about each of these areas in a bit more detail your model is your domain model like I talked about before it's the model of your problem domain so if you're building an iTunes competitor your model will be all about artists and songs and plays and ratings if you're building an accounting app it'll be about accounts and transactions non-visual it's it's due it's a domain model and but importantly because it's non visual and hopefully you architecting it nicely it can be unit tested yep your view model is literally the model of your view or the model of your UI so for let's for a forum for example this would be a model non visual but a model of all of the logic represented by that that form but also all of the data represented by that form so the UI rules the the workflows and the processes that a user might interact with in that form are all modeled inside your view model because it's not visual it knows nothing about edit boxes and buttons and forms it knows about state and it knows about processes view models can also be unit tested the last piece is your view and this is actually the visual rendering of a view model so this is where you have edit boxes and buttons and forms and and basically inside your view you use live bindings to bind the state the data in your view model and display it inside your view and you have the minimum code needed to invoke the methods inside your view model the key thing to realize is that because views are visual they are hard to unit test and so as a result a general goal is to keep the amount of code in a view to a minimum and what code is in there should be super simple because this is the one part of the three sections of our application which is hard to unit test so if it's hard to unit test keep it small and keep it simple so that's mvvm at a high level let's drill in to an example I've got an example application called menial tasks it's a simple task management application it's focused on introducing mvvm and nothing else and I've kept it purposely simple it's just got the bare minimum number of features that are needed to show some key mvvm topics there's no persistence there's no inversion of control I'll talk about that why that matters later on it's it's purposely simple before we start diving into the source code let's begin by running the application so you can get an idea of what it does the first thing you'll notice is this is not a session about creating attractive user interfaces this is very functional very simple keeping the focus on mvvm there are other sessions during code rage on fire monkey and styling and whatever else you like what we have is a simple task application for managing tasks you can see here we have a list of what we'll once we create some we will have a list of tasks we have some buttons to let us navigate through the list and we have a button to let us create a new task and edit an existing task so let's do exactly that let's create a new task a child form comes up we can give it a name or a title set details about whether this task is due and some more details about the task okay and we can save let me create another task same thing again we've now got two items in the list you can see as we navigate through them we can see the details over here if we want to edit an existing task to change something about it we can bring up that same child dialog but in this case it's loaded up with the tasks we want to edit we can make some changes to the details but importantly if we click Save at this point the detail the changes will be saved if we could cancel they'll be discarded and the current values will be retained okay so that's what I'll do so very simple but it gives us a few key things to look at when we're exploring how mvvm works so let's actually have a look at what we have in terms of source code first let's look at this guy this is a package you don't have to use packages in mvvm but in this case I'll explain later why I'm doing it but in this package I have all of my model and my view models okay so this is all of the non view code in my application you can see in my model I have things like a unit which contains my tasks which is just the class nothing terribly surprising in here it's got a string property called a title a string property which is my details add a time which is my du property we'll have a bit more of a look through some of the source code in here later on we also have a task list which is just also again a class has a few properties like count and exposes some functions to add a new task and test whether it contains a task again we'll come back and have a look at in particular one thing about this class but you can see here it just ultimately is a class that contains an object list a tea object list of tea tasks called F tasks yeah so again nothing terribly surprising there if we have a look in our view models we have basically a main view model which maps to our main view our main form and we have a task view model which maps to that child form that was popping up to let us edit and they had an existing task let's never look at this guy let's look at the task view model if we bring this up again it's just a class just an object yeah there's nothing visual it doesn't descend from form or panel or anything like that and you can see it has some properties it has a property which is a task so it's exposing part of our model at this point and it has a property about a boolean property call can save we'll come back to that it has some methods save and cancel let's also have a look at our main view model and again it's just a class nothing visual has constructor has a property which is a reference to our task list from our model so again the view model is responsible for exposing just the relevant pieces of our model to our views yeah we'll come back and have a look at this in more detail when we go up to our XE which if you have a look which which uses that package basically all it contains is a couple of views a main view and a task for you so let's have a look at our main view looks familiar looks like that form we were looking at what we have in here though is really just the pieces that are related to this particular visual representation okay if we look at the source code our view main which is a dissenter from a form has a reference to a view model see this field private field called F view model which is of type T main view model well as we saw before that's our view model class okay so my form has a reference to its corresponding view model notice that while the form knows about all sorts of user interface type stuff there's fire monkey units in here that sort of thing data binding live binding units and it also has a reference to our view model yeah your model domain if you look at the source code for our view model have a look in the users clause the only thing in the users Clause references to the model and to other view models there is nothing in the user's clause there are no dependencies from our view model back to our view okay and if you go one step further and actually look in our model so here's the model sorry here's the model for our tasks the only thing this this has dependencies on or anything it knows about are some system units and other parts of the model yeah same in our model task list it knows about other parts of the model but it doesn't know anything about view models it doesn't know anything about forms so there's a really clear separation so let's have a look at a couple of things first thing I want to look at is how the live bindings exposes the data in our view model inside the view okay and if you've done any if you've watched any live binding sessions or if you've played with live bindings or been seen at an event this won't be a massive surprise so if we focus just on the let's focus on that child form so our view model our task view model has some data to display inside the task and it has some behavior so let's focus on the data if we actually have a look at the corresponding view for you for our task you can see it's got a couple things it has an action list which we'll come back to later on and this guy is our blind source it's actually a prototype blind source and if I bring up the object inspector and have a look at the field definitions in here I've created in my prototype blind source I've created three field definitions a title which is a string a do a field called Jew which is a date time and a field called details which is a string okay so if you've looked at the prototype blind source this just gives me design time fields to map with turbine from okay if we actually bring up the live bindings designer you can see that those feels title do and details are mapped to the corresponding visual controls here so again no massive surprise the last thing that we're doing in my bind source is in its because at design time it's using the prototype fields at runtime I want it to not use the prototype fields but instead refer to my view model in the oncreate adapter event what I'm doing is creating a bond source adapter which is of T object bind source adapter of type T tasks and what I'm passing into this call to create the owner is the bind source the instance that I want it to actually point to the instance of T task is the tasks contained in the view model okay and we can see here there's an I've got a method in here called view model which simply returns my t task view model so I'm saying view model dot task is the instance that I wanted to bind from and because of the names of my fields in my prototype bind source map to the names of the fields in my view viewmodel tasks here we go title details and joob those bindings at runtime work okay so very simple from a live bindings point of view the next thing I want to show in the example or talk about in the example is how the we've just looked at how that data is bound from our view model into our view the next thing I want to talk about is how the methods are called how actions are invoked from the view to the view model it's it's not terribly complex or even surprising but it does offer I think a really clear insight into the separations between view and view model so that's really briefly jump across to some slides on this I'm using actions you don't have to about just like actions in you know normal Delfy application provides some nice features and they do in an MDM mvvm application as well but basically we have three actors for one of a better word involved in this example and the example I'm going to use is the Save button in our view in that child view that we were just looking at we have an action list and I'll show it to you in the source code in a second and one of the actions in it is the save action as you would know from an action list you typically have a non execute and a non update event for each action and in the case of the on execute it's really simple my my on execute event simply calls the save method of my view model okay so super simple let's just jump across quickly and have a look at that here's my task view okay here's my action list the save action of the save actions on execute event calls view model dot save okay so nothing terribly surprising there the the other part of it though I think is more interesting what happens on the on update event of our task and this is where the forum can decide how to represent the state of the save action so is that it currently enabled disabled that sort of thing what this is doing is calling or referring to the can save property of our view model okay which in this particular case is then talking to the task which is part of our model and querying to see if the task is currently valid so it's validating the task the information we've put in if it's valid it's returning true if it's not currently valid because it's missing some piece of information it's returning false okay the view is then deciding what to do with that information and in the case we'll look at its disabling or enabling the action and in turn disabling or enabling the button but I think this is really nice because it clearly shows that the view model is making the value judgment about whether given the current state of the view model whether it logically could save now whether save is a valid action at this point yeah the view model is not making any decision about whether how that's represented about whether there's a button attached to this and it should be enabled or disabled none of that it doesn't know about buttons all it's saying is given everything I know about the state of this view model at the moment so evil would be valid okay the view takes that information and decides how to represent that to the user so in this case disabling the button or enabling the button as it might be so how that actually appear is in source code we can see that in our view model here's a property can save the get can save method is just returning whether our task is valid and in our model where the tasks live is valid is pretty simple from memory get is valid is just returning whether there's a title or not okay as the note I've made here says you know your validation should probably be richer than that but in this case we've decided that the task is valid if it has a title yeah so my view model is saying I can save if my task is valid if my task has a title my view on the other hand takes that information here in my on update event of my action and says well if the view model says I can save then I will enable the action if the view model says I can't currently save I'll disable the action yeah so nice clean separation very clear who's responsible for making what decision the view decides how the state is represented the view model decides what the state is the next thing I want to talk about is displaying a child form because for two reasons number one unless you've got a really simple application you're going to have multiple views or multiple forms second is it really fundamental it's a fundamental decision about keeping these separations I'll talk a little bit later about this debate about versus view first versus view model first but for now just think about the fact that our view model in my case the view model is making decisions about when things should happen because that's where a logic of my view lives and so it needs to make the decision that now it's time to display a form a child form to the user but at the same time remember my model doesn't know anything about the user interface so I don't want it to actually create a form and display to the user because that would break that separation so we have this interesting problem of how does my view model basically display a child form and then get the information out of it while at the same time knowing nothing about the child form and even which particular view might be used to represent it so at its core this is about separating responsibilities the main or the view in this case the main view when we want to display that child form it knows what what child form to use okay the view model all it knows about is what child view model to use so this is the process that we're doing I'll show you the code in a second but the steps are in my main view at startup the main view provides my main view model with an anonymous method to call when this child view is needed okay so when the main view model decides that now I need to display a form to the user it's going to call this anonymous method that was provided by the main view okay so some that start up that happens sometime later on that add add task button is clicked and as as we'll see all that's doing is calling a method on my view model called view model add new task okay amongst other things over in my view model it creates the child view model the task view model for that represents that that child form so it creates that and calls the anonymous method that was provided at startup by the main view passing in this child view model as a parameter okay so we're invoking this on edit task anonymous method back in the main view the anonymous method creates the necessary child view and passes it the child view model that was provided over here in the main view model okay so it's creating the form my main view model knows nothing about the form all my main view model knows about is the child view model it creates the form the child form gives it or the child view I should say gives it a child view model that was provided to it and shows it called show modal or show what what it was appropriate when that child view closes here the anant the rest of the anonymous method runs cleans up you know frees of the form does whatever it needs to refreshes the bindings maybe in the main view but basically that anonymous method returns back to the main view model okay and at this point the main view model still has a reference to the child view model so if it needs to reach in and grab any state or data that was created during that process it has it so effectively what we've got is our main view model all it knows about is the child view models doesn't know anything about the forms or the views that are used to represent them and so it effectively says okay create a main view my child view model now it's time to show this child view model when it's done it's got access to the child view model so I can pull the data out all of the knowledge of the actual user interface elements the forms or whatever that are used to represent that child view model or over here in the main view okay so let's actually walk through that in source code we can see let's get some more space we can see that my main view at startup where are we here is creating an anonymous method okay and the parameters to my anonymous methods are ascender and importantly the child view model the task view model okay and in it what it's going to do when it's called is it's going to create the child view passing in the view model the child view model okay kind of create it it's going to call show modal on it and assuming that that modal dialog closes with the OK button being pressed and not the cancel button it's going to refresh the bindings that are used on this form on the main form and then free it okay it's a pretty simple so it's start it's putting that setting that anonymous method into the on edit task property of my view model okay so let's go over and look at the view model main it has this on edit task property okay and it also has a do on edit task procedure that takes a view model so if we have a look at it all it's doing is checking to see if it's been provided and honest method and calling it passing in the child view model okay the Edit task procedure takes a task creates the child view model passing in the task calls that anonymous method passing in the child view model it looks like there's a few hoops to jump through here but it's a really common pattern that you'll see where essentially the view model is driving the interaction and and what what child view models occur at different points and then the corresponding views are relatively simple thin skins that get applied over the top of it let's actually have a look at what is inside the view so let's go to our task view this child view if you if you have a look at it what does it contain it contains some really simplistic calls over to the view model yeah to invoke actions and to check whether actions in vocable for one of a better word it has a constructor which sets up a few things sets up a reference to the view model that was passed in on the constructor it has some live bindings specific code okay in this case this is code which is essentially auto posting so as soon as a value has changed in the adapter it's automatically pushed back to posted back to the underlying object you don't always want to do that in this particular form I wanted to do that some other code to set up the adapters inside my form and that's it okay so really apart from these calls up here okay which are to the view model this bit of code you could wrap up and put inside some reusable piece the start of your view model framework that you can end up creating this form is relatively dumb okay and really pretty probably you know there's minimal code in here so doesn't really need an awful lot of testing which is good because you eyes are hard to test yeah once you've written code like this one a few times and wrapped it up inside a reusable method then you don't have to keep testing it really the view model on the other hand for this corresponding screen okay this does require testing this is where all the logic of that view is contained so this does require testing as does my model of my task require testing okay and that's where my tests project come in so you can see I've got make this a little easier to see you can see I've got a test project just using d-unit that has some tests for my model so here's the tests checking whether my validating my model and here are the unit tests testing my view models so here's the ones that are testing for example this one test can save empty title so this one's just setting the task title to empty and then checking F task view model Ken Save and checking that that's false because as we saw before if the title is empty the Ken save method should return false okay and if it returns anything other than false in this circumstances we're failing the test here's the flipside when we've got a valid title can save should return true okay and if it returns anything else we fail it we also do some testing to see whether when we cancel a an edit whether those changes are actually canceled or whether they still retain inside the the task object so we can unit test our model we can unit test our view models and get much higher test coverage across all of the logic in in our application the only thing left untested at this point in my application is my actual view and as we just saw the you is really pretty simple and there's not too much in it so this is how you get that I was going to say side benefit but in some ways it's not the side benefit it's the core benefit of mvvm in that much more of your application becomes testable and becomes unit testable so just a few things to think about in the wrap-up you'll run into a few of these concepts when you're reading other articles and other forum posts about mvvm especially in the WPF world so a few things think about you'll see this reference to things called pure views and really this is just a pure view would be a view that contained no code in the back end all of the code was off in the view model or in the model this is a goal that's possibly not achievable or certainly not easily achievable but it's a worthy goal because as we've talked about the less code you have in your view the less code there is in your application which is untested so aiming for minimal code in your view is definitely a worthy goal you reach a point where there's diminishing returns though and trying to get to the point of having no code in your views may not be worth the effort okay we also touched on on this next one before this this argument in the mvvm world about whether view first you know you view model first and this is a really a chicken-and-egg discussion in my example you saw that my view models came first I prioritize my view models first and then I created the view to match the view model there is an approach to mvvm where you create the view first and it is responsible for creating the necessary view model there are advantages and disadvantages to both I've personally find that the when I go view first and let the forms drive the flow of my application I find that my applications become more complicated and more tightly bound your mileage my very so try it both ways I did I decided that I was more comfortable with you model first but try another thing to think about in this example my views were all forms but that actually doesn't have to be so I was very careful to define a view as a visual representation of a view model it doesn't have to be a form and and it's not uncommon to have a view have child views just as a like a main form could have child panels and break break the the layout of the form down into panels sub panels and and you would have a corresponding main view model that had child or sub view models within it representing each of those panels okay so in your mind try and break this connection that that of you must map to a form in Delfy few other things using mvvm doesn't dictate that you do that you use inversion of control or dependency injection but like most applications inversion of control can simplify things and simplify your code and your tests so I've purposely avoided it in this example but in in real life I actually use it I should also mention that you don't need an mvvm framework in the double PF world and silverlight world dozens of mvvm frameworks have popped up and the reason for this is as you go through the process of trying to remove code from your view and write little helper functions and same thing in your view models you know push behavior up into some base view model class or something every time you make those decisions you're basically starting to write your own little mvvm framework so inevitably people end up with mvvm frameworks even if they're the only users of that framework and so you don't need one and but you'll probably end up writing one and then the last thing I would say about this is try it you know nvvm brings a bunch of benefits it also brings some disadvantages there's no denying that there's more code that you have to write the the relationships in some ways are more complicated you know so nothing comes for free there are some disadvantages to this after trying MVC and MVP mvvm was the one that really took for me it may not for you so if you've if at the end of this and try after you try and vvm it doesn't work for you try one of the others try MVC it might it might take for you okay where can you get some more information this session I'm using as the starting point for a series of more detailed blog posts over the coming months on my website so if you're interested in more information I will be posting more detailed stuff as I explore mvvm further over the coming months the source code for this example is available up at github my github page there are a bunch of other resources there that'll dos as an introduction hopefully this has been useful hopefully it's sparked some thoughts I'll leave this page up on the screen at the moment and say thank you for listening and I'm ready to take whatever questions there was a question here have you attempted mvvm with a traditional VCL TV ad source data we're binding mechanism yeah that I haven't I've been purposely one of the reasons I've been really excited about live bindings and I've been hassling Jim and his team mercilessly is because I wanted to do this and so I've been waiting for live bindings to do it there's no reason you couldn't do it with the old the vcl data binding framework it's not as flexible so so you you you know obviously one of the limit limitations of the VCL data binding framework is that the the the source that you're binding from has to be a dassit and so you might have to you know mush or your model down into a data set in order to bind from it but you know it's certainly possible I've never tried it and a couple of people asked the question about the source code and you answered that in the question and answer log that it's saw one on your github at HTTP slash like m mg ROV es su espana slash mvvm list which is the link that you have on the screen so basically all of those resources that are on the screen at the now at the moment or the links that are up there are on my blog behind that URL that you just read out and and that is up on the screen at the moment as I find you know this if your Google mvvm you'll find a million things that you do with most things your Google these are the ones that when I was trying to understand this you know sometime back these are the ones that really could grip I found progressed my understanding there's plenty that you can read that may not as I find more that that sort of progress my my understanding further are I'll update the blog post that's behind that that short URL but all the source is now up on github I published a while the video is playing this that link now works so you know grab it and play with it I guess if if this is sparked some interest and then the sample project you have is using xe3 right because somebody asked what about xz2 i mean you can use any language yeah well depends who you ask actually you I agree you can use any language you'll see lots of references from WPF folks that that mvvm was developed by the WPF team at Microsoft and they did coin the name but they basically there's two answers to that there are JavaScript there are now JavaScript mvvm frameworks for example and in fact one of the the the audience members in the questions pointed out a thing called Delfy sorcery framework which is a Delfi mvvm framework that I wasn't aware of so you can mvvm is just a pattern so you can implement that pattern in all sorts of languages the WPF team did come up with the mvvm name and and an implementation of it for WPF but you know they and they admit this they borrowed heavily from Martin Fowler's presentation pattern presentation model pattern which also it seems like most good ideas in the world come from small talk he borrowed that presentation model pattern very heavily from small talks application model patterns so you know there's very few new things Under the Sun we just keep reinventing it hmm now what is MVC is I don't know how many years old now was back to the you know there's some of the early Smalltalk gave for late seventies just well you're coughing David one of the things that did repeatedly come up in the questions was you know why did I say that this this the downside of this is that it takes more code well and do I mean by that that you can't componentize some of this you obviously can and that was the point I was trying to make about how everyone ends up writing their own mvvm framework and you absolutely can but the reality is that you do have more now more classes to maintain you've got you know you have to jump through some hoops to get certain things done you have to everyoneís to make their own call about whether that extra effort whether that pain is worth the benefit you get from increased testability cleaner separation you know ability to just swap you eyes out easily that sort of stuff yeah there was a questionnaire about other application scenarios where you would suggest not using mvvm and I think you covered some of that in the talk after that was probably please post it as a question but if you want to review that again yeah I mean if it's a simple app if it's if it's if it's like a utility that you know you it's not going to get too complex and it's just there for a purpose then mvvm would probably be way overkill but if this is something that you think it's going to have a long life and it's going to you need to be maintained and extended and it and it's something where you definitely want testability across much more of the logic in your your app that's what I think is the biggest benefit of this is that now I can test and autumn do automated testing on much higher percentage of the logic in my app all of the form logic is now very easily you know testable if you want if your application is complex enough to want those things then you need to look I think it's worth your time to look at one of the MV star patterns MVC MVP mvvm yeah one of them I looked at MVC that years ago and I never really got it guarded in concept but I never really it never really took I looked at MVP kind of same thing mvvm was the first one that I found sort of meshed with my with my brain and and and also I think one of the benefits of mvvm is that because it leverages data binding and in our case live bindings you get some more of that rad productivity that you sometimes lose in in MVC and MVP you know liked and asked I think you answered it or anonymous methods mandatory could use method pointers absolutely you just need some way for the model to delegate out to the out to the view to do something for it it could be a method pointer it could be in a traditional event any of those things and then deal I guess here the leaves but why not merge the view model into the model it would still be unit testable you everyone makes their own decisions about how much separation they want to need for me there's a there's a there's a pedantic answer that I have and there's a probably a more practical answer the pedantic answer for me is that you know then you're mixing your application model your domain model sorry your domain model which is about your problem domain you're mixing in application concepts of you concepts user interface concepts into that model and and then that you know there comes with disadvantages in terms of being out that you reuse that model elsewhere outside this particular app so that's a downside the other thing to realize and I didn't realize this at first it but since I've started exploring this I've run into customers where their model is not actually an object-oriented model it's actually a data model I've spoken with customers and seen their applications where their back-end model is actually they wrap they're basically took their old data modules from their from their older Delfy applications and used that as their model and then the view models job became to pull that information together and present it in an Ohio fashion to the view so so in that case it wouldn't make sense to mix it so much because the model that the backend was was data based that the view models were object-oriented based and then the views spoke to the view model so but there's no nvvm police well there's actually there probably are but you don't they have no power so despite what the mvvm police tell you you do what makes sense for your app yeah I'm Jerry the long we was asking how to sort of map this to two you know certain kinds of application patterns like master detail big lifts things of that kind yeah so in the in terms of master detail basically the view models job is to pull the pieces to expose the pieces of the model that it need that are required by the view to expose those out to the view so the the where the master detail logic lives you know the master detail logic probably lives in your model but the if you're talking about how to bind to them then they're actually in this case the the main view in this sample project actually binds to both the task list object which is what it displays in that grid and also the individual the currently selected task which is what binds over on the right hand side of that view so using the data binding you can reach into different parts of the model for different user interface elements in terms of pick lists I started doing that and ran out of time so it might be actually something that I add to this source code example and the the lookup support and Jim Tina's been posting a bunch of blog posts on the lookup support in live bindings that rocks for for picklists it's really I found it really easy to expose lookup lists and and those sorts of things in my model and in my view model and then bind to them using the lookup capabilities inside live bindings and there's always the question about in in many of these software architectures what about a persistence layer could Davison app for example be the used as some form of persistence persistence out of this because I wanted you know I find that if you throw too many things into a into a demo then you distract from the thing you're trying to teach but you know you could use data snap you could use some sort of orme like the TMS one and there's also that the de ORM open source project and there's the tech insight open source arm for Delfy so the the backend persistence is is usually needed for clearly but it's it's nothing to do with mvvm how you want to persist you doubter and where you want to persist it is an important decision but it's it doesn't impact mvvm and then oh ralph was asking wouldn't most of mvv mvvm i can't do that his thermos is there a move them something some kind of one or two syllables inge be implemented by simply constructing an accurate or comprehensive view of UML model well UML can help you lay out your model and lay out your view models well but if you're not doing any vm you can use it to lay out your model but the problem that I've always struck and that I've heard other people strike is you build this lovely domain model in UML or whatever so you've got this great domain model there and then what are you doing your forms and and so do you put your user interface logic about whether this button you know whether this term is valid it should be enabled or not or which which which information to show at the moment or which form to show at the moment do you put that in your model or do you put it in your form and if you put it in your form then suddenly your form has become complicated and and really you you've gained you've gone Oh Oh at the backend domain model because you wanted the benefits of maintainability and all that sort of stuff but you've lost that with your forms so this really just takes maybe maybe maybe you know in some ways absolutely right this just takes if you've decided that oo is the way you want to do your model for a whole bunch of positive reasons this just helps you stretch that out even further towards the front end and where your view just becomes a really thin skinned laying on top of of your ohio models yeah you know and then let's see todd sends along great presentation i've been trying to convince my boss of the need for lose coupling unit testing and the like you've given me so much ammo for our future conversations things they're always good let's see multiple models in one view let's say you want to display an order a view that shows the order number and matching view model you want to display a list of products different model in the form let's see i'm creating editing the order with the view model also had have a reference to list of products or which you pick list be represented with a second view model that knows only about products this is one of those questions i hade answers when you ask a question like this and people go it depends you can actually do it either way usually the decision to to break up a view into or a view model into into sub view models comes down to how complex it's getting now you know all the standard things have complex it's getting whether you need to reuse pieces like that that product pick list view model that the Jared's talking about that may be something that what you want to use in multiple pair view models around the place so you know unfortunately it just depends mvvm doesn't give you much guidance on on how to how do I say this it shows you how to implement you know what you want to do in a in a nice separated way it doesn't really suggest an awful lot about how you what you should do so you know you still you still need you know mvvm is no substitute for synaptic activity basically you still need to think about how you're going to break this up where you want to create these separations what's going to be complex what's going to need to be reused elsewhere all of those things still apply and this just gives you a framework implementing it I think yeah and Todd gets the award this time for persistently asking the same question it's okay and I didn't miss it why did you put your model and view model into a package there's a couple of things in this video maybe I should do a director's cut at some point when I first recorded this video is way too long so there was a few things that ended up on the cutting room floor and that was one of them in in this case I put the model and the view models into a package because I have a half-finished metropolis so basically what I've done is I've got a window a standard windows form application that loads that package I've also got a half-finished one that I will finish before the C++ version of this a half-finished metropolis version as well that you reuses the same view models and the same models and just slides different views in on the top so that's the reason I put it in a package so that I could shot being loaded there's zero reason for the zero necessity to use a package you could just use this include the same files in in the different projects no problem you know this this example evolved and and I had grand plans about things I was going to do at the start which contracted as the as the deadline approached so package is just a deployment decision and and doesn't really impact mvvm yep and again I'll refer everybody to Malcolm's blah Malcolm groves calm where he says yes he will do some more detailed blog posts about this over the coming months and so on yeah basically I was I've got a few actually pending that are mostly written I was waiting and wanted to use this as the starting point so I didn't have to write all of this stuff up someone can watch this video and then I go into more detail like for example the the the lookup list business I've got one race mostly written on that one written path written on inversion of control and how that can help in vvm that sort of stuff

Channel: Embarcadero Technologies

Views: 16,895

Keywords: Embarcadero, MVVM, Delphi, Mobile Studio, CodeRage 7, LiveBindings

Id: Ci1HP8ZBJxk

Length: 57min 12sec (3432 seconds)

Published: Mon Nov 19 2012