On naming a namespace, which one is better?

Question

2.00/5 (2 votes)

See more:

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:

C#

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:

C#

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.

Posted 14-Feb-16 15:51pm

Member bi-dongliang

Add a Solution

2 solutions

Solution 2

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

C#

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);

Posted 15-Feb-16 0:59am

BillWoodruff

Updated 15-Feb-16 1:34am

v3

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Abhinav S · Accepted Answer · 2016-02-14T16:00:00

Solution 1

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.

Posted 14-Feb-16 16:00pm

Abhinav S

Comments

Member bi-dongliang 14-Feb-16 22:19pm

Then, which grouping style is better, by functionality or by constructs? In our case, subsystems are packed as assemblies given Print.dll, Scan.dll and so on.

Sergey Alexandrovich Kryukov 14-Feb-16 23:11pm

Wrong question. It depends on the role of UI, Reader, etc. For each option, one can find two architectures, one better with first naming, another better with second one.
Namespace are not so much important, but do care of readability and ease of navigation through code.
—SA

Sergey Alexandrovich Kryukov 14-Feb-16 23:09pm

This is exactly true, a 5. But last sentence is wrong. First, readability criteria depends on semantic, what aspect has the priority. Second, the readability can be made formally the same if one simply reorder the directives.
—SA

StM0n 15-Feb-16 0:54am

I agree... except the last sentence... if you put it in a different order, the readability is also given.

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

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

but still a 5 ;)