1/16/2008
Pain Points of Using XAML or WPF
Pain Point 1: XAML always create the controls by its default constructor
This means, you need to have a default constructor for you control, and the constructor will always be used by XAML. So, you can not use constructor dependency injection to pass things like services, gateways to your control. Also, you will not have chance to pass data in constructor, although the data might be must-have for the specific type of controlPaint Point 2: can not control XAML to create or not to create some part of GUI
Sometimes, the GUI is not static. It could be dynamic because the GUI would be different for the data it is presenting, such as for a meeting in the past it should show a adding note button, for a meeting in the future it should not. And more often, the security control requires the GUI to be different according to the role.Paint Point 3: XAML is using XML, which contains too many visual noise
compared to things like YAML, XML is definitely not very friendly to our eyes. The things worse than XML I can come up is the braces of Lisp. Also, XML makes it harder to edit manuallyPaint Point 4: Layouting in Grid
Using grid layout currently requires you to specify the row and column for all the children of a grid. It is very error-prone when the grid becomes large. But grid is a must-have for any non-trivial GUI, and there is not replacement for it yet.Paint Point 5: Things not checked in compiling time
There are lots of things not checked by the compiler in XAML. Things like binding, resource looking up for example. And it is harder to cross reference between xaml and code.Paint Point 6: More files
one file for xaml one file for cs. It requires more steps to create a new user control and is confusing to new comers.Paint Point 7: Separating concerns
the default way events get handled is in the partial class of the XAML. It is not a good way of separating concerns and not good oo design. the windows and user controls usually doing too much in rich client application. It is not the fault of XAML in general, but it is not promoting a good model either by its weird way of hooking up event in xaml.Paint Point 8: Hard to test
It is hard to test in many ways. First, not easy to inject dependency means you can not mock those expensive things like network connection. Second, creating a real window is taking more than ten seconds. Third, many things are in a static singleton model like resource looking up and the single instance application object.Paint Point 9: Control lazy created with uncertain lifecycle
controls of list item in a list view were lazy created. We can not get those controls easily, and we even can not be sure they are created or not. only those who are visible will be created.
Comments:
<< Home
I think many of these pain points are not very strong and valid points. (note that my experiences developing with XAML are still limited) Let me explain:
#1
Not always, but often a default constructor is good thing. It eases for example things like serializability. Dependency Injection can easily be done via a helper method or public properties.
#2
XAML is static and declarative markup. It would be silly to be more than that because then you would effectively writing another programming language in XAML. So all advanced 'dynamic' behaviour should be done in the partial class.
#3
XML is verbose, but it is also very portably, standard, easy to read and generate. I'd rather have XML markup than some binary file!
#4
Not much to say about this, doesn't bother me much actually.
#5
I don't know about this, not much experience yet.
#6
A good IDE like VS.net can links these files making it easier to use. As in #2, both languages are necessary and therefore (at least) two files.
#7
Seperation of Concern is important, but single responsibility and cohesiveness as well. Event handelers should be handled by the control as well, however these should be more very simple methods that call out to other interfaces, such as your business layer or data layer.
#8
UI testing is notoriously difficult and fragile. The trick is to create very simple UI controls and move all more complex behaviour to classes that you CAN test. (That is why you probably do not need dependency injection in your XAML controls .. this kind of complexity will factored out of the control).
#9
No experience with this yet.
Post a Comment
#1
Not always, but often a default constructor is good thing. It eases for example things like serializability. Dependency Injection can easily be done via a helper method or public properties.
#2
XAML is static and declarative markup. It would be silly to be more than that because then you would effectively writing another programming language in XAML. So all advanced 'dynamic' behaviour should be done in the partial class.
#3
XML is verbose, but it is also very portably, standard, easy to read and generate. I'd rather have XML markup than some binary file!
#4
Not much to say about this, doesn't bother me much actually.
#5
I don't know about this, not much experience yet.
#6
A good IDE like VS.net can links these files making it easier to use. As in #2, both languages are necessary and therefore (at least) two files.
#7
Seperation of Concern is important, but single responsibility and cohesiveness as well. Event handelers should be handled by the control as well, however these should be more very simple methods that call out to other interfaces, such as your business layer or data layer.
#8
UI testing is notoriously difficult and fragile. The trick is to create very simple UI controls and move all more complex behaviour to classes that you CAN test. (That is why you probably do not need dependency injection in your XAML controls .. this kind of complexity will factored out of the control).
#9
No experience with this yet.
Subscribe to Post Comments [Atom]
<< Home
Subscribe to Posts [Atom]