在命名命名空间时，哪一个更好？ [英] On naming a namespace, which one is better?

问题描述

鉴于大型应用程序，有许多子系统，以子系统打印，扫描和编辑组成的应用程序读取器为例，哪个命名空间命名样式更好？



第一个命名模式：

 Company.Reader.Model; 
 Company.Reader.UI; 
 Company.Reader.Print.Model; 
 Company.Reader.Print.UI; 
 Company.Reader.Scan.Model; 
 Company.Reader.Scan.UI; 

第二种命名模式：

< pre lang =c＃> Company.Model.Reader;
Company.UI.Reader;
Company.Model.Reader.Print;
Company.UI.Reader.Print;
Company.Model.Reader.Scan;
Company.UI.Reader.Scan;

或者，还有更好的选择吗？任何建议将不胜感激。



我尝试过：



我们目前使用的第一种命名方式没有深入考虑。

解决方案

这取决于你是否想要通过他们为例如他们所做的各种功能对你的项目进行分组。读者与你是否想要将结构（模型，UI等）分开。



第一个提供更好的可读性。

我的投票基于以下观点：关注点分离应尽可能在每个语义选择中显示：

 命名空间公司
 {
  public   enum  DataSources 
 {
 Oracle ，SqlServer，MySQL，ADO 
} 
 
  public   enum  PrinterNames 
 {
 LaserWriter1，DotMatrix1，Xerox1，Xerox2 
} 
 
  public   enum  ScannerNames 
 {
 Nikon1，Canon1 
} 
 
  namespace  ReaderApplication 
 {
  namespace  Controller 
 {
} 
 
  namespace 模型
 {
 命名空间打印
 {
} 
 
 命名空间扫描
 {
} 
} 
 
 命名空间 UI 
 {
 命名空间打印
 {
} 
 
 命名空间扫描
 {
} 
} 
} 
} 

但是......你有时间和精力进行这种精心设计吗？根据现实世界的限制，架构将从几乎没有到高度正式。



你是否会满意需要你的课程的一些外部用户需要编写这样的代码（伪代码）：

使用Company;< br /> 
使用Company.ReaderApplication .UI.Print; 

为了在某些UI环境中进行这样的调用：



PrintDispatcher.Dispatch（CurrentPrintJob，PrinterNames.DotMatrix1）;

Given a large-scale application, with many subsystems, taking application "Reader" composed by subsytems "Print", "Scan", and "Edit" for example, which namespace naming style is better?

The first naming pattern:

Company.Reader.Model;
Company.Reader.UI;
Company.Reader.Print.Model;
Company.Reader.Print.UI;
Company.Reader.Scan.Model;
Company.Reader.Scan.UI;

And the second naming pattern:

Company.Model.Reader;
Company.UI.Reader;
Company.Model.Reader.Print;
Company.UI.Reader.Print;
Company.Model.Reader.Scan;
Company.UI.Reader.Scan;

Or, is there any better choice? Any suggestion will be appreciated.

What I have tried:

We currently use the first naming style with no deep consideration.

解决方案

It depends on whether you want to group your projects by the various functionality they do for e.g. reader versus whether you want to keep the constructs (models, UI etc) separate.

The first gives better readability though.

My vote, based on the idea that "separation of concerns" should be made as visible as possible in every semantic choice:

namespace Company
{
    public enum DataSources
    {
        Oracle, SqlServer, MySQL, ADO
    }

    public enum PrinterNames
    {
        LaserWriter1, DotMatrix1, Xerox1, Xerox2
    }

    public enum ScannerNames
    {
        Nikon1, Canon1
    }

    namespace ReaderApplication
    {
        namespace Controller
        {
        }

        namespace Model
        {
            namespace Print
            {
            }

            namespace Scan
            {
            }
        }

        namespace UI
        {
            namespace Print
            {
            }

            namespace Scan
            {
            }
        }
    }
}

But ... do you have the time and energy for this kind of elaborate design ? Depending on the real-world constraints, architecture will vary from virtually none to highly formal.

Are you going to be "happy" requiring some external user of your classes to need to write code like this (pseudo-code):

using Company;<br />
using Company.ReaderApplication.UI.Print;

In order to make calls like this in some UI context:

PrintDispatcher.Dispatch(CurrentPrintJob, PrinterNames.DotMatrix1);

这篇关于在命名命名空间时，哪一个更好？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！