Comments on: Separation of Concerns while programming WPF with XAML http://blog.lab49.com/archives/182 Technology and industry insights from Lab49. Sat, 24 Sep 2011 08:33:50 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Terry Sansom http://blog.lab49.com/archives/182/comment-page-1#comment-54453 Terry Sansom Fri, 18 May 2007 03:48:50 +0000 http://blog.lab49.com/?p=182#comment-54453 I’ve been working with XAML for a variety of applications, and could not agree with you more about the importance of discipline when deciding on how much code should be written on the XAML side, or kept on the C# side. I’ve not run any rendering performance tests but I’d be curious to know if there is any rendering differences. I also think the discipline of presentation to business logic is actually improved with XAML: We now we have a language that is fully capable of generating a rich user experience, and we can focus our C# efforts on your business and data abstraction layers. Then again I’ve written a handful of converters to assist the UI in consuming the business logic. I hated XAML in the beginning but now with 6 months under my belt, I’m considering rewriting several legacy applications in WPF. I’ve been working with XAML for a variety of applications, and could not agree with you more about the importance of discipline when deciding on how much code should be written on the XAML side, or kept on the C# side. I’ve not run any rendering performance tests but I’d be curious to know if there is any rendering differences.

I also think the discipline of presentation to business logic is actually improved with XAML: We now we have a language that is fully capable of generating a rich user experience, and we can focus our C# efforts on your business and data abstraction layers. Then again I’ve written a handful of converters to assist the UI in consuming the business logic. I hated XAML in the beginning but now with 6 months under my belt, I’m considering rewriting several legacy applications in WPF.

]]> By: Terry Sansom http://blog.lab49.com/archives/182/comment-page-1#comment-54451 Terry Sansom Fri, 18 May 2007 03:48:25 +0000 http://blog.lab49.com/?p=182#comment-54451 I’ve been working with XAML for a variety of applications, and could not agree with you more about the importance of discipline when deciding on how much code should be written on the XAML side, or kept on the C# side. I’ve not run any rendering performance tests but I’d be curious to know if there is any rendering differences. I also think the discipline of presentation to business logic is actually improved with XAML: We now we have a language that is fully capable of generating a rich user experience, and we can focus our C# efforts on your business and data abstraction layers. Then again I’ve written a handful of converters to assist the UI in consuming the business logic. I hated XAML in the beginning but now with 6 months under my belt, I’m consirering rewriting several legacy applications in WPF. I’ve been working with XAML for a variety of applications, and could not agree with you more about the importance of discipline when deciding on how much code should be written on the XAML side, or kept on the C# side. I’ve not run any rendering performance tests but I’d be curious to know if there is any rendering differences.

I also think the discipline of presentation to business logic is actually improved with XAML: We now we have a language that is fully capable of generating a rich user experience, and we can focus our C# efforts on your business and data abstraction layers. Then again I’ve written a handful of converters to assist the UI in consuming the business logic. I hated XAML in the beginning but now with 6 months under my belt, I’m consirering rewriting several legacy applications in WPF.

]]> By: manung http://blog.lab49.com/archives/182/comment-page-1#comment-361 manung Fri, 09 Dec 2005 15:56:50 +0000 http://blog.lab49.com/?p=182#comment-361 In essence, yes XAML is a kind of serialization format. I have read an open debate on whether XAML would make a good generic XML serialization format besided being used for WPF and WWF. But I guess we will have to wait and see how XAML shapes up in the future. In essence, yes XAML is a kind of serialization format.

I have read an open debate on whether XAML would make a good generic XML serialization format besided being used for WPF and WWF. But I guess we will have to wait and see how XAML shapes up in the future.

]]> By: Damien Morton http://blog.lab49.com/archives/182/comment-page-1#comment-254 Damien Morton Tue, 06 Dec 2005 15:51:41 +0000 http://blog.lab49.com/?p=182#comment-254 manung - so what youre saying is that XAML is a kind of serialization format? manung – so what youre saying is that XAML is a kind of serialization format?

]]> By: manung http://blog.lab49.com/archives/182/comment-page-1#comment-250 manung Mon, 05 Dec 2005 18:28:10 +0000 http://blog.lab49.com/?p=182#comment-250 Yep, As I paraphrase Don Box here ... All XAML is an XML Binding to .NET objects. No more no less. In essence XAML is good for declaring objects and there dependencies. Note that XAML is not only for presentation, but could be used in other paradigms in which you need to declare objects and their interdependencies. XAML makes it easier to create Visual Designers for these object declarations. For example one good candidate is workflow, hence WWF. I am still thinking how XAML could fit into another growing Software Engineering pattern of Inversion of Control and Dependency Injection. Right now I am leaning toward that XAML was not design for IoC and DI, but could be used as a tool for it along with some othere classes in the .NET Framework. As of now like everyone said above, you can declare your objects in XAML, but the behavior of those objects all goes "behind". Yep,

As I paraphrase Don Box here … All XAML is an XML Binding to .NET objects. No more no less.

In essence XAML is good for declaring objects and there dependencies.

Note that XAML is not only for presentation, but could be used in other paradigms in which you need to declare objects and their interdependencies. XAML makes it easier to create Visual Designers for these object declarations. For example one good candidate is workflow, hence WWF.

I am still thinking how XAML could fit into another growing Software Engineering pattern of Inversion of Control and Dependency Injection. Right now I am leaning toward that XAML was not design for IoC and DI, but could be used as a tool for it along with some othere classes in the .NET Framework.

As of now like everyone said above, you can declare your objects in XAML, but the behavior of those objects all goes “behind”.

]]> By: Doug Finke http://blog.lab49.com/archives/182/comment-page-1#comment-249 Doug Finke Mon, 05 Dec 2005 16:22:05 +0000 http://blog.lab49.com/?p=182#comment-249 Cider Cider is a XAML design time editor within Visual Studio. Visual Studio will have intellisense on the XAML and will keep the XAML and cider surface in sync. In fact, the internal XAML formatting is also preserved by Cider. This is what a developer would use to build the code behind a XAML UI. Video of Cider Demo http://channel9.msdn.com/showpost.aspx?postid=129619&pvrid=152 Cider
Cider is a XAML design time editor within Visual Studio.
Visual Studio will have intellisense on the XAML and will keep the XAML and cider surface in sync.
In fact, the internal XAML formatting is also preserved by Cider.
This is what a developer would use to build the code behind a XAML UI.

Video of Cider Demo
http://channel9.msdn.com/showpost.aspx?postid=129619&pvrid=152

]]> By: Tyler http://blog.lab49.com/archives/182/comment-page-1#comment-248 Tyler Mon, 05 Dec 2005 15:27:20 +0000 http://blog.lab49.com/?p=182#comment-248 yup, let's hope that the world chooses wisely. yup, let’s hope that the world chooses wisely.

]]> By: Jason Dolinger http://blog.lab49.com/archives/182/comment-page-1#comment-247 Jason Dolinger Mon, 05 Dec 2005 15:21:51 +0000 http://blog.lab49.com/?p=182#comment-247 Tyler, I agree with you, I hope that is the case. It seems that XAML will provide a good way to separate the presentation. It's not necessarily what XAML/WPF provides, it's how we choose to use it. Tyler, I agree with you, I hope that is the case. It seems that XAML will provide a good way to separate the presentation. It’s not necessarily what XAML/WPF provides, it’s how we choose to use it.

]]> By: Tyler http://blog.lab49.com/archives/182/comment-page-1#comment-246 Tyler Mon, 05 Dec 2005 15:19:14 +0000 http://blog.lab49.com/?p=182#comment-246 ugh, as someone who has written XSLT and attempted to develop applications that users have to interact with I find this a bit unnerving. Coding logic in an XML framework is truly a miserable undertaking (unless it is uses the javascript methodology, but why go down that road?!?!) and I was hoping that XAML might actually help separate the presentation. I was also thinking that because in .NET 2.0 the concept of partial files allows the presentation to be split into a different file than the logic, this presentation part could be written in XAML. Maybe this is actually the case in how cider and sparkle work. ugh, as someone who has written XSLT and attempted to develop applications that users have to interact with I find this a bit unnerving. Coding logic in an XML framework is truly a miserable undertaking (unless it is uses the javascript methodology, but why go down that road?!?!) and I was hoping that XAML might actually help separate the presentation.

I was also thinking that because in .NET 2.0 the concept of partial files allows the presentation to be split into a different file than the logic, this presentation part could be written in XAML. Maybe this is actually the case in how cider and sparkle work.

]]> By: Luke Flemmer http://blog.lab49.com/archives/182/comment-page-1#comment-245 Luke Flemmer Sat, 03 Dec 2005 15:57:49 +0000 http://blog.lab49.com/?p=182#comment-245 I agree; the tendency to do it all in the XAML is something that has bothered me too. The only reason that a world in which all code lives in XAML instead of living in the form's C# would be (slightly) better is that XAML is more declarative than imperative. That being said, I do believe that the patterns that will be successful will be those that treat the XAML as declarative view definition, with a .NET model behind it. I agree; the tendency to do it all in the XAML is something that has bothered me too. The only reason that a world in which all code lives in XAML instead of living in the form’s C# would be (slightly) better is that XAML is more declarative than imperative. That being said, I do believe that the patterns that will be successful will be those that treat the XAML as declarative view definition, with a .NET model behind it.

]]>