Designer vs. Code Window a.k.a. VB.NET vs. C#

With Whidbey looming on the horizon, Microsoft keeps telling us about how VB.NET is advancing from the RAD/designer enhancements and C# is enhancing the code window. As more time goes by the more I’m convinced that this is not a good direction for MS tools.

 

I work in a shop that consists of both VB and C# developers. Those of us that came from a C++/Java/Javascript background have found C# more comfortable, while those with mainly VB experience prefer VB.NET. Quite honestly there is still quite a debate about which language is better. I tend to believe that the language syntax is irrelevant, especially when compared to many of the other development challenges that we face.

 

More and more I see VB.NET developers writing a lot of code in the code window that is much easier managed by an existing designer. This ranges from management of connection strings via the web.config/app.config, to the setup and configuration of SqlCommand objects. I find myself repeatedly espousing the virtues of the VS.NET designers. The thing that seems odd to me is that I do most of my coding in C# and I’m the designer evangelist. The VB guys keep telling me: “Oh I prefer to write the code myself”. This seems exactly backwards to the message I keep getting from MS. Whidbey is being marketed as further defining these language “personalities”. VB is an iterative RAD/visual experience where as C# is a code window experience. I find this to be false in practice.

 

In some cases I think it is purely a lack of understanding about what the designers can do for you. I don’t mean to give the impression that the designers solve 100% of your problems. I just truly believe they are very underutilized. I have honestly seen code that dynamically creates rows in an ASP.NET data grid with no calls to DataBind(). I’ve seen code that builds up html by concatenating strings, not with a string builder btw, and then updates the Text property of a label control.

 

I can’t say enough good things about the data binding architecture in ASP.NET. I find that by carefully organizing the code with data binding in mind, I can easily wire up an aspx/ascx with little more than a few calls to DataBind. However, I see a lot of VB.NET code that overloads OnDataBinding rather than a lot of <%# %> blocks in the ASPX page. Another data binding rarity is the use of a data binding  expression to define the data source such as: <asp:DataGrid datasource=’<%# dsCustomers %>’ runat=”server” />.

 

There have also been a few attempts at applying OO principles to ASPX pages by deriving new “basepage” types from Page. The code behind class for all the pages in the site then inherit from this base page. This technique works well for encapsulating some of the common functionality of the site but in some cases the developers have broken the designers. So far I seem alone in my attempts to ditch development paths that outright break the design time environment. This isn’t to say that you should never derive a new Page class. Rather, if you do create a new page class and the code you’re putting in it breaks the designer, you’re probably doing too much in the base page. This also leads other junior developers to believe that the designers are flawed and sacrifice your OO principles. I’ve dubbed this “Fighting the designers”.

 

Maybe I’m just a data binding/designer bigot. That being said I am completely jazzed about the idea of “code window” designers. C# and Whidbey seem to be moving towards the idea that you can have the IDE help you input and change the code faster. From the code window perspective the IDE should help me visualize, document and implement patterns much more rapidly than notepad. I think this makes sense for the development of the business logic component tier and that the visual designers make sense for the UI/Web Server tier.

 

I’d really like to hear what other peoples experiences have been with the designers. Do you love them? Do you hate them? Are they better in some languages than in others? Microsoft, please separate this developer personality idea from any particular language and make it purely a function of the IDE.

5 Comments

  • &quot;In some cases I think it is purely a lack of understanding about what the designers can do for you.&quot;



    Or it could be more accurately stated as &quot;In some cases I think it is total understanding about what the designers can do to screw you. &quot;

  • I don't know of many cases where the designer is worth using. You claim to be a designer evangelist, please clue me in. All I have seen the designer used for is &quot;ooo! ahhh!&quot; demos that demonstrate RAD features that could/should/would never be used in a production environment.

  • I do admit that I haven’t delved into the data access application block to much. I will be looking into it more though as your sample above looks very enticing. I really don’t have that big of a problem with setting the DataSource property in code and then calling DataBind. There are simply many cases where the DataSource can be encapsulated in a property and then an expression can be used declaratively in the page (e.g. DataSource='&lt;%# GetCustomers() %&gt;'.



    I have looked at the code that is produced by the designers. The code looks very similar to what I'm going to write by hand. Create an instance of a connection object, create an instance of a command object, create many instances of parameter objects and populate the command's parameter collection with them. This is exaclty the operations that will be done by SqlHelper.ExecuteDataSet(connectionString,&quot;spName&quot;,p1,p2,p3); If I use it. I do wonder how that method can be implemented without some form of reflection against the parameter types though. I'm wondering how it builds its command objects. I'll look into this more.



    The designer basically seems to generate a lot of code that is nothing more than instantiation of objects and property set operations. I guess I don't see the problem with the code the designer generates. This just seems like a code ownership issue. If I didn’t write the code then it’s no good. Look for this to get more of a hot topic in Whidbey when they move all the designer generated code out into a partial class so you cant even see it in your class.



    This sounds very similar to the arguments made about C++ back in the early days when it was just a pre-processor. Have you seen the C code generated by that C++ pre processor? Blech!!! How bloated is that? Granted, it took a while for C++ to mature. But no one really questions the validity of using OO and C++’s features today.



    I think visual designers for UI, Patterns (UML), Data Bases etc. will be much more of the norm in the future. There seems to be a whole class of developers that like modeling things out in a UML tool then generating code from that (*cough* Java). I personally don’t like generating code from the modeling tools today. I think they still need some work. But the general trend in system integration is towards designers in my opinion.



    When you get to the integration phase the code is not pretty. It is not very OO like. It’s just a bunch of instantiating objects and wiring them together. At some point all the object modeling has been done and the only way to get an application out of this pile of objects is to write procedural code. This is where the designers shine. They help you write that “glue” code. If you build your components in such a way that they support the designers rather than break them, the integration work can be greatly simplified. The designers are not perfect, but they are better than they have ever been in the past.



    Heck, go build a component that encapsulates all the data access. Just build it so the UI developer can drop it in and set some properties with the property box and move on. At the end of the day the hard core developers can live in the code window writing components. I believe they should be writing them to enable the RAD design time in VS.NET so that the more junior devs and, dare I say, even HTML slingers can build out the UIs quickly and efficiently.



    I realize that I probably give to much credit to the designers. Thats why I want to hear about all the issues that people have with them.

  • By dragging and dropping database connections to a form, you violate some of the key principles of a maintainable architecture, even in reporting.



    I don't like dragging and dropping database tables to design XSD, but then I am most comfortable with XML Schemas and different approaches for designing content models. And the XSD designer itself is, well, poor if you don't know the minutiae of XSD content models and types alreeady. But I do like the ability of the designer to validate my schema, and the XML designer is great for allowing me to validate XML against a schema. My point is that not all aspects of a designer are drag and drop visual elements, some are additional capabilities in an otherwise &quot;code window.&quot;



    Probably the 1 designer that I absolutely love is the CSS designer. It allows me to quickly set a lot of properties, but I always end up cleaning up after it.

  • If you want to be uber-leet then ditch VS.NET all together and go code in notepad while those who can handle the designer (possibly because we want to get our jobs done quicker!?) can get on with their jobs easier.

Comments have been disabled for this content.