﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Ayende Rahien commented on .Net Testability</title><description>Because winforms are stateful, databinding can be a real killer here, especially when you want to do it two ways.
  
I tend to avoid it at all cost, I would rather write code to do the shuffling (or write a framework for it :-) ) than deal with it. About a year ago I spent a few days going over the databinding approach in WinForms.
  
It is very powerful, if you are using datasets.
  
Otherwise,  it makes a lot of false assumptions (Like I would care to implement interfaces on my model just to get databinding).
  
</description><link>http://ayende.com/2183/net-testability#comment7</link><guid>http://ayende.com/2183/net-testability#comment7</guid><pubDate>Thu, 08 Mar 2007 21:30:45 GMT</pubDate></item><item><title>Jeremy Miller commented on .Net Testability</title><description>I'd agree in regards to WinForms.  You can even treat small controls as just plain classes, and the MVP abstraction doesn't leak like WebForms.
  
  
Data binding is a pain though.  I'd bypass data binding for non trivial cases if you want testability.
</description><link>http://ayende.com/2183/net-testability#comment6</link><guid>http://ayende.com/2183/net-testability#comment6</guid><pubDate>Thu, 08 Mar 2007 21:25:11 GMT</pubDate></item><item><title>Ayende Rahien commented on .Net Testability</title><description>WinForms are a lot easier to test (in theory) because it is simple to simply pump the correct messages to the application.
  
From there you can start doing more interesting work. It is also the case that I can do a new Form() everywhere I want, which is an important quality when I need to test.
</description><link>http://ayende.com/2183/net-testability#comment5</link><guid>http://ayende.com/2183/net-testability#comment5</guid><pubDate>Thu, 08 Mar 2007 21:18:37 GMT</pubDate></item><item><title>Adi commented on .Net Testability</title><description>Do you also hold this view in regards to winforms, or only ASP.NET?
</description><link>http://ayende.com/2183/net-testability#comment4</link><guid>http://ayende.com/2183/net-testability#comment4</guid><pubDate>Thu, 08 Mar 2007 21:16:12 GMT</pubDate></item><item><title>Reshef commented on .Net Testability</title><description>True.
  
I used to be an ASP.NET control developer in my previous job and the time ratio between development of runtime features and design time features was about 1:9. 
  
It makse us have bigger dll's blown up code and of course it is good only for Demos/Trivial scenarios.
  
No serious web developer that I know is using the dseign time features so it is also a waste of time and energy...
</description><link>http://ayende.com/2183/net-testability#comment3</link><guid>http://ayende.com/2183/net-testability#comment3</guid><pubDate>Thu, 08 Mar 2007 15:21:40 GMT</pubDate></item><item><title>Ayende Rahien commented on .Net Testability</title><description>O agree with you 100%, the problem is that Microsoft is looking for great demos, and it build the tools accordingly.
</description><link>http://ayende.com/2183/net-testability#comment2</link><guid>http://ayende.com/2183/net-testability#comment2</guid><pubDate>Thu, 08 Mar 2007 06:05:05 GMT</pubDate></item><item><title>James Kovacs commented on .Net Testability</title><description>I believe that the fundamental problem is that RAD makes for great demos and lousy maintainability. Wizards typically only help you the first time when creating a project, page, or other artifact. (There are a few exceptions where you can use the wizard to edit the item, but these are few and far between.) Unfortunately the majority of software cost is most often incurred during maintenance (and enhancement) and not initial development. So choosing tools that make initial development easier (i.e. drag &amp; drop, wizardy stuff) and maintenance or enhancement harder is the wrong way to go, IMHO.
</description><link>http://ayende.com/2183/net-testability#comment1</link><guid>http://ayende.com/2183/net-testability#comment1</guid><pubDate>Thu, 08 Mar 2007 06:03:21 GMT</pubDate></item></channel></rss>