Just getting to the end of this book, I wanted to write about the interfaces which defined the communication between the view and the logical object, specially the information that the view passes to the logical layer and whether we should use finer interfaces with individual getters for each field (used by David in his book), to a coarse interface with one getter returning a data structure.
Passing Simple fields accross
By simple fields, I mean fields that do not need validation, an string, an integer an enumeration are considered a simple fields. However a decimal is not, since and decimal is built from a string but it needs validation to be built.
This approach has the advantage of leaving the view completely ignorant from any sort of logic. The logical object asks for each single simple fields to the view and them he builds an object or an entity, e.g. a movie, while he carries out the validation.
In this case the View is acting as both, a service (Movie displayer) and a view Model (the Movie). Mixing these two responsabilities can be a problem when we has multiple views of a movie. As well it can obscure the test verification phases, where seeing the the view as a service can make hard to implement the equality.
Passing a view Model (Interface segregation)
In this case the View acts as a display service (Movie displayer) of a View Model (the movie). Even thought the concrete view class can still acts as both we could separate the movie into its own interface.
In this case, we can end up with a Movie view Model, and Movie logical object, very similar between them, but the first being a data structure while the second is an object with behaviour. For example in the case of the movieView, the ratings, are a vector, while in the movie are an array. Another example will be an amount field, while in the view will be an string the object would have it as a decimal so easily implement operations on it.
This allows to narrow the movie view, in pretty much two methods: "displayMovie" and "getMovie", passing an Movie view Model, which can easily implement equality to help in test verification.
If the view model is shared by different view this approach make sense. The downside is that increments complexity by segregating a new interface which will have to be converted from and to the object.
Passing the object
Having the editor talking to the view using the objects can reduce complexity by using one only object (Movie).
The issue here, it is easy that logic leaks into the view, since building the logical object can easily require validation.
Conclusion
I believe the key here is avoid having logic within the view, specially validation.
Fields entered in the view will have to be validated before they form
The key here is when do we do the data validation captured on the view.
The other key will be how fine/coarse grain we will like our view interface.
The third one will be avoid complexity when not needed.
At the moment I would avoid the "Passing the object" approach which is likely to break the first key. I would start with "Passing simple Fields", and I would refactor if needed into "Passing a view Model".
Passing Simple fields accross
By simple fields, I mean fields that do not need validation, an string, an integer an enumeration are considered a simple fields. However a decimal is not, since and decimal is built from a string but it needs validation to be built.
This approach has the advantage of leaving the view completely ignorant from any sort of logic. The logical object asks for each single simple fields to the view and them he builds an object or an entity, e.g. a movie, while he carries out the validation.
In this case the View is acting as both, a service (Movie displayer) and a view Model (the Movie). Mixing these two responsabilities can be a problem when we has multiple views of a movie. As well it can obscure the test verification phases, where seeing the the view as a service can make hard to implement the equality.
Passing a view Model (Interface segregation)
In this case the View acts as a display service (Movie displayer) of a View Model (the movie). Even thought the concrete view class can still acts as both we could separate the movie into its own interface.
In this case, we can end up with a Movie view Model, and Movie logical object, very similar between them, but the first being a data structure while the second is an object with behaviour. For example in the case of the movieView, the ratings, are a vector, while in the movie are an array. Another example will be an amount field, while in the view will be an string the object would have it as a decimal so easily implement operations on it.
This allows to narrow the movie view, in pretty much two methods: "displayMovie" and "getMovie", passing an Movie view Model, which can easily implement equality to help in test verification.
If the view model is shared by different view this approach make sense. The downside is that increments complexity by segregating a new interface which will have to be converted from and to the object.
Passing the object
Having the editor talking to the view using the objects can reduce complexity by using one only object (Movie).
The issue here, it is easy that logic leaks into the view, since building the logical object can easily require validation.
Conclusion
I believe the key here is avoid having logic within the view, specially validation.
Fields entered in the view will have to be validated before they form
The key here is when do we do the data validation captured on the view.
The other key will be how fine/coarse grain we will like our view interface.
The third one will be avoid complexity when not needed.
At the moment I would avoid the "Passing the object" approach which is likely to break the first key. I would start with "Passing simple Fields", and I would refactor if needed into "Passing a view Model".
No hay comentarios:
Publicar un comentario