RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


The Two Faces of .NET : Page 2

Developing applications with .NET sometimes feels like I'm working with a split personality. Now that .NET has been around long enough, I and many of you undoubtedly have had a chance to put .NET through its paces with some real applications rather than just little samples. For me, the .NET learning curve has been a long one. I find working with .NET both exciting and frustrating at the same time. Talking to other developers I think I'm not alone.

The Bad
Although I am very excited about .NET as a platform, I find it infuriating to work with at times. A lot of things are difficult to do or are implemented in a nearly incomprehensible fashion when it seems that there could have been easier and cleaner interfaces. Like any 1.0 release from Microsoft there are a number of unexpected behaviors. It seems like .NET is making some difficult things easy and some easy things more difficult.

My number one beef with .NET centers on databinding, both in Windows Forms and Web Forms. .NET databinding mechanisms try to do too much by trying to address 100% of scenarios at the cost of significant complexity rather than address 95% of scenarios and making databinding easy. Yes, the databinding mechanism is very powerful with its ability to bind anything to anything. The ability to page through data is good. But you must write a lot of code by hand to accomplish this. So much, in fact, that it's almost easier to bind data to controls manually than use the default databinding functionality. In Windows Forms specifically, you must manually write databinding code and when you're done the code can't be controlled via properties on the controls the data is bound to. For example, try binding a textbox to a property of a business object rather than a field from a dataset and see how much code you must write to display the data and keep it updated as you move through a list box. It isn't pretty. You can do it—it's just very tedious and very error prone because much of the code you write deals with indirect referencing (that is, it's not type-safe) and you don't get IntelliSense or the compiler to help you out. If you do use DataSets exclusively, life becomes a little easier because you can use the Builders, but this process still takes too much time and you end up with reams of unmanageable code.

Not only does it take a lot of code to perform these tasks, but the mechanism involves a number of different objects. Just understanding how databinding works is a major task. Forget trying to figure it out from the .NET docs. Several third-party articles and books explain databinding, but even with a good description the topic is confusing at best. No doubt the power is all there. For me, the solution was to build my own databinding subclasses to simplify the process of adding properties to my custom controls that I can set in the property sheet. After all, if you write database applications, almost all controls are databound and you surely don't want to write code to bind each and every control manually.

.NET can do many tasks that previously required splitting things out into other tools.
Databinding in Web Forms, thankfully, is simpler, but it also has a major problem: It is one-way only. You can only display databound data. You can't write databound data back to the data source. It's hard to even call this behavior databinding. Granted, ASP.NET makes the population part easy by using the form controls to retrieve the data, but this still leaves me scratching my head as to why there isn't some way to grab the data from the controls and bind them back to the data since the control binding is already there. Just about every single data-driven Web page needs to do this, so why isn't this built-in?

Along the same lines, data validation is far from trivial. Instead of providing easy tools and masks on the various controls, you must use external objects and extra event handlers to make validation work. You must create lots of code and there are many opportunities for errors. Whatever happened to simple format string-based validation that covers the 90% scenario? .NET opts for completeness and complexity instead of the ease of use. As developers we can address this with wrapper classes, but since most of us will rewrite this stuff over and over again, why couldn't this functionality have been included in the Framework?

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date