I have a layered application with namespaces:
App.Core - business layer logic services
App.Data - data access layer store classes and data access objects
App.Web - user interface layer
I also have business objects/DTOs. They reside in App.Objects namespace, but I dont like this naming convention. Why? Because this namespace will also have subnamespaces suffixed Objects like App.Objects.KeywordObjects. These subnamespaces can't be without the Objects suffix, because some of them will also contain classes with the same name (App.Objects.KeywordObjects will contain Keyword and Keywords classes).
I was thinking of changing App.Objects to something else. So I don't have duplicate "Objects" word. But I can't seem to find any usable word. And I don't want to use acronyms like DTO or BO.
How do you normally name your namespaces and what would you suggest I should use in this case.
I'm a fan of the guidelines in "Framework Design Guidelines" by Brad Abrams et Al, which would give you:
YourCompany.BusinessArea for your business objects and YourCompany.BusinessArea.Web for your web layer. I seem to remember there was also a guideline that an object shouldn't rely on a nested namespace (but you could rely on a parent namespace)
Namespace depth should correlate to frequency of usage. Why not put them in App? If your application revolves around the business objects, it makes sense to keep them at or near the root.
For a practical comparison, for many business applications the business objects are analogous to keeping common types in System. They are pervasive.
Here are some suggestions:
App.Contracts
App.Entities
Giving things a good name is hard to do. The best thing I can suggest is find something that works for you and try your best to be consistent in style and tone. This is easier said than done.
“When I use a word," Humpty Dumpty said in rather a scornful tone, "it means just what I choose it to mean - neither more nor less.” - Lewis Caroll
I normally use common acronyms freely (so I wouldn't mind using App.BO, personally), but if you always have the Objects suffix in the subnamespace I think App.Business reads nicely, e.g App.Business.KeywordObjects with that "business [something] objects" phrase. (If you don't always have the Objects suffix for subnamespaces then this suggestion wouldn't work as well, as things would read strangely).
I would make the following change
App.Core => App.Services
App.Objects => App.Core
or
App.Objects => App.Model
App.Business ?
Related
I was often wondering about the right way to do this:
For example, in my program I have around 100 constants (or enums) that are used in some calculation. They should preferrably be stored in one place. They can be grouped hierarchically, for example:
System3 / Rules / Rule7 / ParameterXY / MaxAverageValue
Naturally, I want those values to be accessible while coding, so storing them in some kind of ressource is not really an option.
As far as I could tell, this can be done with:
very long constant names
nesting classes
namespaces
Using names is quite ugly, and it's not really well maintainable. I find nesting classes a nice way to do it, but some stylecop/fxcop rules forbid that, so this must be "bad" in some way. Lastly, I find the suggested alternative, using namespaces, not terribly nice neither. Imho it creates masses of folders and files that each contain almost nothing. And I don't like when 50 sub-namespaces pop up in the assembly reflector.
So.. how do you do this kind of task? What would you suggest?
very long constant names
This is sort of gross, but at least it is discoverable. All your code would reside in the same place so you wouldn't have a problem finding it.
I find nesting classes a nice way to do it, but some stylecop/fxcop rules forbid that, so this must be "bad" in some way
One reason it is is bad because automated code generation/code inspection tools are harder to work with. Another reason is that it is harder to discover these with Intellisense.
The most important reason this is bad is because a nested class should be strongly associated in an object-oriented dependency sense for the layout be make sense logically. In all but some rare cases (e.g. Enumerator classes) it won't make sense. In your case it also doesn't make sense because your classes don't really have any behavior or object orientation at all - they're just a hierarchy of constants.
Namespaces
For the problem you described, this is the best way to handle it. You get the least clutter per-level, and you get Intellisense while typing so you can see what you're narrowing down to while descending through the hierarchy.
Imho it creates masses of folders and files that each contain almost nothing
If you really need a huge pool of constants, and it doesn't make sense to bind them to other parts of your application, then this is one of the rare cases that I'd abuse the one-file-per-class and one-folder-per-namespace rules. The only reason you're even stuffing them into classes at all is because .Net doesn't have support for global variables.
Another suggestion
Do you have domain-specific objects that these constants belong on instead? E.g. is there any logic related to the System3 / Rules / Rule7 class? Is that not some sort of actual business rule that you should embody with its own class?
If you can arrange your code so that you have a thicker domain model, then the most logical place to put your constants is on the classes that embody the corresponding domain logic.
If it doesn't make sense to have a thick domain, you have fully generic rules processing, and you are relying on constants to feed your business engine logic, then you have a data-driven application. This means you should store your data in configuration files, not in code.
How often is each constant re-used in multiple methods? You could consider reorganizing your constants. If you still find yourself with huge numbers of constants, try putting them in a static class with read-only properties.
If you just need a good place to look at them all in one place, you could also look at storing them in the app.config file and you can access them through AppSettings and the ConfigurationManager class.
Well the way I do this is to have a sealed file called Constants.
so
public sealed class Constants
{
//for e.g.
//Sessions
public const string APPSESSIONKEY = "AppType";
}
Than I use this in the rest of my project and the importance here is what you will name it as it will help you remember it and make sense when you need it.
By calling it in your code.
Constants.AppSessionKey
You could also
Create an Assembly whose only purpose is to hold constant values for the project. Every other Assembly should then reference this one. Following DRY and KISS, since adding references is simple enough. Main problem here is recompilation.
We use Resources files with a custom T4 template that generates a static class hierarchy with readonly string fields for the values.
The keys in our Resource file are separated with '.' to build the hierarchy.
We can have separate resource files that are compiled into one class hierarchy.
I know that nested classes is not recommended but in my opinion, for a situation like this it is the nicest solution.
I am working on a simple project and I have created several classes, interfaces, one static class and so on. What I am asking is, how to organise this files into namespaces. Is there any good practice for this or I should just follow the logic of my program. I am currently thinking that I should move the interfaces into one namespace and all the classes into another. So what can you advise me. I am really curious to find out the best way to separate my files.
Have a nice day :)
You should group your code in namespace with other types which have the highest cohesion. That is, group types together when they perform common functionality. The type of cohesion you're suggesting is logical cohesion, and is really a rather weak form of cohesion.
Namespaces are mainly for the benifit of large projects. Since you are working on a "simple project", I suggest that you use a single namespace for the entire application. Since everything in C# must be a type or a member of a type (i.e., there are no global variables or methods), the types that you create (objects, classes, interfaces, enums, etc.) are usually a good-enough organizing feature for a small project.
For slightly larger projects, I suggest putting each tier into its own namespace.
For even larger projects, namespaces should be a logical grouping of related types or subsystems, according to preference.
Into specific namespace you should put everything which concerns some matter. For example all the stuff concerning string manipulations you should put into separate namespace, e.g. com.server.string.
It's very important especially in case you have class with names existing in other namespaces.
The only reason to split your code in files is to make your code maintainable.
As a general rule of thumb, I tend to create folders for enum's, struct's, models, controllers, etc. Depending on the size of the solution, you keep nesting in groups after that.
Sometimes it makes sense to just put the entire namespace in the file, other times, you let your nesting take care of the naming.
A good rule of tumb is that you should be able to find what you are looking for quicky, and, more importantly, someone who hasn't seen the project, should find his way around quickly.
One thing to keep in mind is that you never put more then one thing in one file. Never put two classes in the same file, never append enums at the end of a class file, etc.
You are confusing files with classes. You can create folders in Visual Studio to organize your files. That way you can group interfaces and classes (which is what I usually do). VS will automatically put new classes for which the file is in those folders in the namespace of the same name. This is usually not what you want (I don't know how to turn it off, so I can't help you with that).
I agree with the other answers here that you should group types based on what they do, not on what kind of language construct they are.
Well i have just been through my rather large project and used correct namespacing (within the naming conventions) so i have things like Models, Service, UI etc.... all the standard stuff..
AND I HAVE DRAWN A BLANK :-)!!
I have quite a few enumerations, constants and things like that which i need to extract them from a generic class i have and insert them into a class/project of there own so i can add a reference to it from all my projects that need it.
Can anyone suggest a good naming convention for holding enumerations and constants etc.. I thought about using CompanyName.Product.Enumerations but there again its NOT just enumerations..
I was hoping for a little input or advise and good namespace naming structure for this sort of project (holding enumeration, collections, and constants)
Thanks in advance
The enumerations should live in the same namespace as the types that use them - don't create namespaces that organize things by how they are designed.
Just think - would you create namespaces like this?
Comp.Project.Classes
Comp.Project.Structs
Comp.Project.Interfaces
No, because that doesn't mean anything and provides no contextual information about the types that are contained there. Enums are just like any other type - they belong in a namespace that has contextual meaning to the enum itself.
well, usually I would recommend against seperating them. The same resons apply as why I don't like "toolbox" projects that end up as a code-dump.
Can't you simply let your other projects reference your current assembly?
It sounds like you are seperating elements that are vital to your Business Rules, why not draw the name from that area?
Maybe some something like CompanyName.Product.Reference as assemblyname, then specify further using Reference.Constants, Reference.Enums etc?
What should go into the top level namespace? For example, if I have MyAPI.WebLogic, MyAPI.Compression, etc. If I put classes into the top level namespace, am I violating the principle of encapsulation?
Namespaces are not for OOP related concepts like encapsulation. There for organization, so organize it in a way that what makes sense to your application. Most the work I do on websites has a business library and most often it's all tucked under a single namespace.
Depends what the classes are.
One guideline I try to follow is that dependencies between namespaces shouldn't follow a cycle. In other words, low-level namespaces can't access types from higher-level namespaces.
This means that the top-level MyAPI namespace must contain either:
High-level code: code that's allowed to look inside MyAPI.WebLogic and MyAPI.Compression
Or, low-level code: code that's used by MyAPI.WebLogic and/or MyAPI.Compression
Patrick Smacchia has written a lot on the advantages of structuring your code in this way, including on this site: Detecting dependencies between namespaces in .NET
Depends on what the namespace is for really. If its an application then perhaps something like bootstrapper classes, loaders etx, Main's etc. I'd say (as with everything) "it depends".
I don't think you're really violating encapsulation per se by doing that.
Normally namespaces are just a way to organize your classes to make them easier to find, so whatever makes sense for your app.
You're not violating encapsulation at all as far as I see it. In fact, I'm not even sure this can be called encapsulation, given that namespaces aren't specific to OOP - its rather just the orginsation of types.
The rule is simply to place a type in the top-level namespace if you feel it belongs there. An obvious example for this situation is when (using your examples) MyAPI.WebLogic and MyAPI.Compression (perhaps as well as others) all need to utilise a certain type - it is therefore best just to put this type in MyAPI. If you're still not quite sure what belongs, use the Microsoft libraries as examples. There are plenty of classes in the System namespace within the BCL!
I'm having some problems to come up with a sane type naming scheme for our new line of applications. I want to follow the .NET Framework Developer's Guide - Design Guidelines for Developing Class Libraries, but I'm starting to wonder if that's such a good idea.
I'd like to use the Company.Product.Feature namespace scheme as a basis.
Problem 1: We have our own control and form base classes, and I want these to go into the Company.Product.Forms namespace. However, according to the guidelines, we shouldn't let our type names be Control or Form, even if they are in our own Company.Product.Forms namespace, since they will clash with system types.
Problem 2: We have some distinct feature areas in the application and I want these to go into their own Company.Product.Feature namespace. Lots of these features have similar design, with a controller and some views, so under each Company.Product.Feature namespace I'd like to have types named Controller, SomeView, AnotherView, etc. However, according to the guidelines, we shouldn't have the same type names in different namespaces.
The only solution I see to overcome these problems is to prefix the types with something that in some way makes the namespaces redundant. Or not?
Microsoft clearly favors some redundancy. A common example is:
System.Xml.XmlDocument
General class names, even bound within a proper named namespace can cause headaches for the many programmers who like to avoid fully qualifying their class instantiations. "Document" could be an Xml, Html or word document. This ambiguity will cause endless confusion if you happen to import more than one namespace with a "Document" class.
I'd prefer Company.Product.UI, for some reason. I would use that naming for the web, too.
Regarding problem 1, if these are base types, you might include Base in the class name.
Then, you typically have a set of domain specific controls, which won't clash with built-in types.
If you also keep wrappers for common UI controls(TextBox, DropDownList etc), then i would actually recommend use a prefix for them,
maybe this prefix is an abbreviated name of the product.
And then, if you do that, then you might want to be consistent, and do it for all types,
regardless of whether they are ambigious names or not.
I tell you from my own experience.
You'll end up constantly hovering over variables to see their full type names, etc, you will use aliasing etc..
The code will be harder to read.
Problem 2: While at GUI layer, i tend to break these rules, because you will want naming consistency(common verbs; Show,Edit,List). If the guideline tells you otherwise, i would believe it is because it is simply not specific enough.
First post here in StackOverFlow, on an old question. Please, be kind with me :)
General class names, even bound within a proper named namespace can cause headaches for the many programmers who like to avoid fully qualifying their class instantiations. "Document" could be an Xml, Html or word document. This ambiguity will cause endless confusion if you happen to import more than one namespace with a "Document" class.
Microsoft MIGHT sometimes favor some redundency but it's not always de case.
As for the Document vs XMLDocument problematic, when you know there might be more than one type of document, why not just include the qualifying part of the namespace in the declaration?
For example :
Xml.XmlDocument
vs
Html.HtmlDocument
Instead of importing the XML and HTML namespace, why not just include the containing namespace? It would become like this :
Xml.Document
vs
Html.Document
If it makes logical sense, then do it. They are just guidelines, not the LAW. (not that you cant break that too.)
Having classes in the with the same name in different namespaces is just is against the guidelines for a reason, it makes reading the code just a little bit harder because when you see "Controller" you have to mentally map it to "Feature1.Controller" or "Feature2.Controller".
I would prefer to use Company.Product.Features.Feature1.Feature1Conroller with the redundant information or maybe Company.Product.Features.Feature1Controller if it bothers you (and I personally don't like having too many namespaces).
But feel free to break the guidelines, rules are there to make you think before you break them :-)