Amanda Silver - Demonstration of code separation in next version of Visual Basic

All sorts of applications, but mostly web applications now involving many tiers of business logic. 

The thing I've found the hardest to deal with, is HTML designers--they don't like it when we render HTML code in the code behind, so we're forced to put some of the rendering code in the display portion of the ASPX page. If there was only a way to switch them to the other side of the force...

She has a Microsoft coffee cup! Manip wants one .. even if used .. expect to see me going though your office trash bins in the near future

The blurb sez "how that'll help you in your Visual Basic development," but I disagree.  I see that definition of a class can be done piecemeal -- a fraction here, a fraction there -- and that that would be convenient, for example, in automated code generation scenarios.  The code behind of a form contains code generated by the IDE and code written by the end user programmer.  Those two pieces are easier to handle when separated.

But, to return to the main point, Amanda showed me how the mechanism works, but not how it will HELP ME.  What does it buy ME?

Partial class looks interesting...  But under what sort of scenarios would a developer use it?

In addition, having your code spread out like that, would that not make maintenance more difficult?  Or did I misunderstand partial class altogether?

Partial classes are mainly useful in scenarios where code generation is involved. Whether that's the Visual Studio designer or your own code generation system doesn't matter, partial classes will be useful.

Basically, if you're generating code, you're going to want to have some way for the programmer to extend the generated code. And you're going to want to do that in a way that lets the programmer treat the generated code as a black box, and most importantly in such a way that regenerating the code will not overwrite your programmer's code. As anyone who's dealt with code generation can tell you, hand-crafted code is holy!

There are several possible solutions.
You can have the generated code in the same file as your code. This is what Visual Studio does in the current version. The problems with it is that it messes up the file. It becomes harder to read your code because of the designer-generated code that's in between it.
You can have the generator create some class, and then you inherit from it. And you can have the generator create some class that inherits from you. Both methods have the disadvantage that you're creating two classes that describe usually just one entity, and where the base class makes no sense without the child class. So you're making a separation where there should not be one logically.

ASP.NET actually uses that last one with code-behind files (I'm not talking about Visual Studio now, just ASP.NET itself). You write a code-behind class, ASP.NET generates one from the aspx file that inherits from your class. This happens the first time a page is accessed by a browser.

Now anyone who has written aspx files with code-behind without using the VS.NET designer knows this has a very big problem. For every <SomeControl ID="SomeID" Runat="server"> in your aspx file, you need a Protected SomeID As SomeControl in your code-behind file. If you're using the designer, it makes sure your code-behind declarations and aspx controls keep in synch. But if you don't like the designer, and like me write aspx code by hand, it's up to you to keep those declarations correct.

The code-beside model (partial classes) fixes that. Now the ASP.NET runtime creates a partial class from the aspx file. Because these merge into one logical unit, any declarations that the ASP.NET runtime generates are automatically visible in your partial classes, so there's no need for repeat declarations.

For the WinForms designer, the advantage is that your own code file is less cluttered with designer-created code.

I can't offhand think of a situation where it'd be practical to write partial classes by hand, but there probably are some anyway.

It will be more usefull in Longhorn and Avalon sepecificaly because you can define you UI part of your class in a XAML file and the code in the other part of the class in a CS file (in C# for exemple).

But I'm sure programmers will find other creative ways of using it .

In collaberative projects, partial classes should come in useful. But, if you split pieces of logic in a class between multiple people, wouldn't that get messy after a while?

Partial classes isn't just fluff. Like I said, it's a great feature when dealing with code generation.

In fact, I'm working on a code generation system myself, and I'm wishing I could use those partial classes. But since I'm targetting .Net 1.1, I can't do that.

For stuff like the ASP.NET runtime, the XAML compiler, etc. partial classes is a much needed, and from my developer point of view, much welcomed, feature.

For stuff like the Windows Forms designer, the need is less there, mainly because of #region, but it's still a cleaner separation of designer-generated code and hand-crafted code than what's done now, while avoiding the trouble associated with an inheritance based solution.

I don't think it'll be so useful for manual coding. Separating hand-crafted code over many files may lead to maintenance problems. And I think that if you have a class that's so big it warrants spreading over more than one file, you probably need to rethink your design.

Also, they've not added "everything they can think of" yet. Don't forget that VB.NET 2005 is also getting generics, unsigned types (way overdue) and operator overloading. Those are also much welcomed features.

 

I agree with what Sven Groot has mentioned. Intensive usage of these partial classes may lead to some maintenance issues too. And also, it could as well be a design aspect when you need to write a huge code in a single class. But this concept sounds to be more useful in the auto code generation environments.

Ok, so tell me why I would want to use a Partial Class over say a Base Class?

Not trying to be a Troll, but I'm trying to see the advantage of using a Partial Class over an Object Hierarchy.

I don't necessarily buy the "It's Better for Code Generation" argument as that can be accomplished the using either method.

Brien

Partial classes is a really neat feature and it has alot of legitimate uses. This is also one feature that has a great potential of being misused.

I worked on a project (VB6/ASP) one time (remember I didn't write it, I just had to maintain it) which had a DLL with one class in it. This one class in the DLL contained every function/method that was used throughout the application. The purpose of this DLL was to be a layer between the ASP page and the Database. When I maintained this app, I was working with 3 other programmers and we had to coordinate changes to this VB6 Class that needed to made all at the same time. Even though this is a really bad practice and you should never design an app this way, this is still a prime candidate for misuse of the Partial class functionality. I could see a programmer that has very little design knowledge seeing Partial classes as a perfect solution to break up that one class into multiple code files that each contained a certain set of functions/methods.

I know there is no way for the VB Team to really solve this, since it's all the programmers responsibility to learn how to correctly create classes. I just wanted to bring this up since this is a perfect example of a really bad misuse of this functionality.