Tech Off Thread

9 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Usage of namespaces in .NET Framework

Back to Forum: Tech Off
  • User profile image
    Klaus Enevoldsen

    I was just wondering why Microsoft did not use more namespaces in the .NET Framework.

    The namespace System.Windows.Forms has like a million classes, enums and stuff in it. Why not split it up in sub namespaces? Eg. one per Windows Forms Control?

    System.Windows.Forms.DataGridView could contain all the classes and enum etc. for the DataGridView (all column type etc).

    In .NET 2.0 the namespace takes a lot of time to browse... [C]

    I wonder if Microsoft could change it in a future release of the .NET Framework? Smiley Ok, it would break code, but a upgrade wizard could do the trick. Cool

  • User profile image
    littleguru

    The convention says that you have this kind of type for namespaces:
    CompanyName.Product.Feature

    In .NET the company is "System". After that you have the product (or technology) which is "Windows" and then the feature of that product (technology) "Forms".
    I guess you won't see this changing in the future.

  • User profile image
    Klaus Enevoldsen

    Oh, but does the convention say anything about namespaces below Company.Product.Feature? Does the convention only allow 3 levels of namespaces? :O

    Both System.Windows.Forms and System.Web.UI are becoming quite big and I think it is a growing problem.

  • User profile image
    Tyler Brown

    Extending the .NET Framework's namespaces as you've suggested would make the lives of developers that much more difficult. Namespaces make it easy to classify classes by purpose, and also allow you to include a whole set of classes so that you don't have to explicitly specify which namespace a given class is located in.

    Specifying a unique namespace for each WinForms control as you've specified would make including namespaces useless, as you'd essentially be specifying the full namespace for each individual control. I personally think that the 'namespace map' for the .NET Framework is fine just the way it is.

    However, I don't make use of WinForms, as my experience with the .NET Framework has started with WPF (Avalon). Perhaps the WinForms namespace does need some restructuring. In general however, I find that everything's fine the way it is.

  • User profile image
    Klaus Enevoldsen

    Have a look at http://msdn2.microsoft.com/en-us/library/k50ex0x9

    Try to find anything in that namespace... Big Smile

    In the top of the help file it even devides the namespace into 7 categories, so something tells me that the namespace should be subdevided.

    Personally I think that including/importing namespaces is a bad thing. I always write the whole name of a class, sure it's a little longer to write, but there are no doubt about which class that is actually used (eg both System.Windows.Forms and System.Web.UI.WebControls has a Class called Label).

    The advantage of not using include/import is that you learn where the class is placed in the namespace hierachy.

  • User profile image
    W3bbo

    Klaus Enevoldsen wrote:
    Have a look at http://msdn2.microsoft.com/en-us/library/k50ex0x9

    Try to find anything in that namespace...


    Easy Smiley

    Ctrl+F

  • User profile image
    mrichman

    littleguru wrote:
    The convention says that you have this kind of type for namespaces:
    CompanyName.Product.Feature

    In .NET the company is "System". After that you have the product (or technology) which is "Windows" and then the feature of that product (technology) "Forms".
    I guess you won't see this changing in the future.


    Makes you wonder why it's not "Microsoft.Windows.Forms"

  • User profile image
    W3bbo

    mrichman wrote:
    Makes you wonder why it's not "Microsoft.Windows.Forms"


    Because cross-platform GUI "forms" aren't Microsoft-specific, unlike Microsoft.DirectX or Microsoft.VisualBasic.CompilerServices, for example.

    All "System.*" namespaces are up to running implementation of the CLR to think of.

    In Windows, the .NET CLR would simply use GDI/MFC for System.Windows.Forms

    But on Linux, the MONO CLR might use GTK.

    ...Unless you're refering to the "Windows" bit.

    I think that's because the namespace deals with "window objects", not the "Windows" platform.

    I wonder what other namespaces could be in there... System.Windows.Dialogs? System.Windows.3DDesktop?

  • User profile image
    Harlequin

    You can also use namespace aliases in your code, then if you don't like System.Web.UI.WebControls, you can call it WhaleBlubber if you want Smiley

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.