Yesterday, I wrote about why I think partial types were redundant. I apologize for jumping the gun there without enough research required to make such a comment, and held my opinion (a bit adamant on my part) even when Frans, Wesner and others commented saying its a nice feature to have. Since then, I have tried to learn more about this construct, the help it provides with code generation and more, to a developer.

As Frans mentioned

 If some team goes bezerk over this feature, I think it's more a problem related to management than to  the developer. I mean: what's so hard to understand about:
- one part is for code generation
- one part is for extension through custom code.

Basically, when I was was busy mentioning XAML/ASPX + inheritance, I forgot to see the manageability issues from a POV other than mine. Lately I have been negative, its the time to get into a positive mindset.

So, for a team that knows their bit, and don't mess up too much, here are some points.

• Separating generated (and regeneratable) code from the custom logic is a plus. I got my mistake right after seeing a set of autogenerated Data Access Layer classes, where the generator provided only CRUD functions, and no functions for running stored procs, mainly because it did not generate the stored procs and views. Writing such functions elsewhere (in another class) would harm our purpose of creating a class that works over Data Access on a table. I think partial types provide a good scene here.
• Consider ASP.Net. I have worked on a product that creates an eCommerce website, given a database. We wanted to give away a set of heavy themes with these web-sites, we had to go for a page class for each web-page.

  

  Because the aspx pages and their related javascripts, controls, structure of user controls were so different, we decided to have a separate aspx + code behind class for each web-page for each logical web-page in all templates. The code behind classes for a page in all templates referred to a single page class. With partial classes, there is no need of such a design, or should I say, its inherent. There are some issues btw, when you move up from v1.1 to v2.0(beta and +)  -
  
  1. There will be two files to manage. The code behind class, as with all generated classes, will be divided into 2 partial classes. One with custom logic, the other with the declarations (can be private now). So if you are upgrading, remove the declarations from the code behind class, the IDE will generate these in a partial class.
  2. The web-page/aspx class will inherit the consolidated class(the compiler will consolidate both/more partial classes) at runtime, and hence work similarly to the way it works in v1.1. New command line compiler.
  3. There are attributes which you can set to keep the process the way it works in v1.1. Also, if you have your v1.1 code behind class compiled in a different assembly, you can keep it that way.
  

• Windows forms - By adding one more function call, to a private method in the same object, you can actually separate, like asp.net, the windows design from processing logic(calling BL functions etc.), so its easy for a team to separate work on UI logic from UI design. I know this must have been done before by somebody, by inheriting from a form that has protected functions/something like a page class above, its just that after compilation, it will be a call to private functions in the same object.

OK, so this was the part where I came to know how to manage stuff using partial types, and use this construct constructively. I still had my doubts as to what lead to its inclusion. I asked Craig Andera, and am very grateful that he replied, even though I have never had any communication with him before, and I am more or less an anon. This is what he had to say-

  There are many problems with inheritance. For one, it forces you to use up your one and only base class somewhere, which isn't necessarily always what you want to do. It also means you don't get access to private member variables, which, in some codegen scenarios, is a useful thing. But really, inheritance is just too big a hammer to solve this problem: designing classes correctly for inheritance is really, really complicated, when all you really want to do is just to generate some code and then add or alter one or two methods.

Hopefully, I have apologized enough.