Joined the NMVP open source project
I joined the NMVP open source project on codeplex, i ll be busy in the evenings implementing Convention over Configurations, and Rapid Web NMVP Assembly that will facilates the framework use !
January 2, 2007
Refx:: DSL Tools, démonstration d’un designer MVP (translation in english follows)
Depuis quelques temps, je tombe fréquemment sur des articles au sujet des DSL de Microsoft. Je me demande systématiquement : « pourquoi un autre langage de modélisation ? UML remplit bien ses fonctions et quand bien même, non seulement je ne crois pas en une modélisation forward blueprint (une modélisation exhaustive en début de projet), mais en plus, cette pratique va à l’encontre de mes principes d’agilité »
Ces lignes vont vous montrer pourquoi j’ai eu tort de tourner la page. (more…)
November 22, 2006
OBSEV: Model View Presenter w/Command (DataGrid)
This weekent went fast, i didnt really have time to work on a sample code . Here i post a sketch, a class and a sequence diagram, showing an example of Model View Presenter with a command pattern implementation , for a datagrid.
The initBinder method on the binderObject subscribes it to the deffirent events of the datagrid.
then treatement can be added for the deffirent events.
DataBinders with xml mappping can be provided, so that reflexion can be used to map model to the dataBinderObject at run time. (more…)
OBSEV: Model View Presenter w/Command (sadek)
Thinking about Martin’s Article, and the MSDN extension of MVP,I realize the importance of this pattern. I even see that a whole extension framework can be built on this pattern, I will explain more…
I believe in the dumb view, a view that doesn’t contain any logic, not even data binding.
Martin’s MVP together with the MSDN’s article answered several questions, and showed ways to keep the view really clean, but we sacrifice ASP.net’s productivity (DataSource xml mappers, binding mechanism…etc )
But here comes a question, should we really sacrifice all of that? The answer is yes and no!
In my point of view, yes we should avoid putting logic in the page handler, I know that wizards are easier, but they are not healthier! This binding and mapping mechanism live in the code behind, which is not unit tested, that means a source code that can grow buggy, and yet not covered by the tests.
But the good news is, No we don’t have to forget about productivity, as long as we are capable of creating our healthy ways to do it.
In my observation I will try to suggest solutions to these kind of problems, u are free to take it, to like it, or not. Anyway any comment will be helpful to develop the solution.
My solution is inherited from the Command Pattern (GoF).
Back to the dumb view, so we move all the logic to the presenter, and we leave the code behind with properties and events, and we subscribe the presenter to these events.
The DataBinding is done by a command object, actually I am calling it command just to remind that all commands share the same interface, with one method (the Execute() method) and these commands encapsulate the logic.
I don’t guess that sticking to the strict definition of the command pattern is important, we can have the Interface having more than one method, the most important thing, is to share the interface with one or more executing methods .
Following sketch is a class diagram and a sequence diagram that illustrates the interaction between the the page (view) , the presenter, the command and the model.
The benefits of such a model is to avoid code duplication by providing the data binding logic , encapsulating it inside a class, and providing the possibility of implementing an xml mapping to the model (using app.config or even custom configuration files that look like the asp.net DataSource mapping).
I believe in the dumb view, a view that doesn’t contain any logic, not even data binding.
Martin’s MVP together with the MSDN’s article answered several questions, and showed ways to keep the view really clean, but we sacrifice ASP.net’s productivity (DataSource xml mappers, binding mechanism…etc )
But here comes a question, should we really sacrifice all of that? The answer is yes and no!
In my point of view, yes we should avoid putting logic in the page handler, I know that wizards are easier, but they are not healthier! This binding and mapping mechanism live in the code behind, which is not unit tested, that means a source code that can grow buggy, and yet not covered by the tests.
But the good news is, No we don’t have to forget about productivity, as long as we are capable of creating our healthy ways to do it.
In my observation I will try to suggest solutions to these kind of problems, u are free to take it, to like it, or not. Anyway any comment will be helpful to develop the solution.
My solution is inherited from the Command Pattern (GoF).
Back to the dumb view, so we move all the logic to the presenter, and we leave the code behind with properties and events, and we subscribe the presenter to these events.
The DataBinding is done by a command object, actually I am calling it command just to remind that all commands share the same interface, with one method (the Execute() method) and these commands encapsulate the logic.
I don’t guess that sticking to the strict definition of the command pattern is important, we can have the Interface having more than one method, the most important thing, is to share the interface with one or more executing methods .
Following sketch is a class diagram and a sequence diagram that illustrates the interaction between the the page (view) , the presenter, the command and the model.
The benefits of such a model is to avoid code duplication by providing the data binding logic , encapsulating it inside a class, and providing the possibility of implementing an xml mapping to the model (using app.config or even custom configuration files that look like the asp.net DataSource mapping).
This example is quite simple and straightforward as it is about the simplest databinding (which is to a drop down list)
Later I will provide another observation , with a more sophisticated example, illustrating more functionalities (update,delete,edit).
Later I will provide another observation , with a more sophisticated example, illustrating more functionalities (update,delete,edit).
Refx >> Model-View-Presenter for Asp.net
Martin Fowler talked about the Model-View-Presenter in his blog , then he came back and splitted it into 3 patterns :
Presentation Model, Supervising Controller, Passive View
The degree of seperation between model, controller and view varies in each of the three.
I recommend reading Martin’s articles about the MVP for deeper understanding of the patterns.
Follows is a REFLECTION, an article in msdn Magazine, implementing the MVP in asp.net, quite interesting, Especially on this event based web framework.
The degree of seperation between model, controller and view varies in each of the three.
I recommend reading Martin’s articles about the MVP for deeper understanding of the patterns.
Follows is a REFLECTION, an article in msdn Magazine, implementing the MVP in asp.net, quite interesting, Especially on this event based web framework.
The author chose to present the Model View Presenter using Test Driven Development, pointing it out (MVP) as solution for implementing the TDD approach in asp.net .
