What is the recommend naming convention for classes in a multi-tier-application?

Question

I sort of have naming problems of my classes/namespaces/controls.

In my business library I have namespace called Shopping. It contains the following classes: ShoppingCartItem
ShoppingCart
ShoppingCartManager

In my ASP.net application I want to create a control that graphically represents the items of a ShoppingCart instance. Normally, I would call that control ShoppingCart, but yet another class called ShoppingCart? Of course compilation et cetera would work, but I think its still ugly. I think I have a problem that I name my business classes excatly what they are supposed to represent. Because when it comes to the presentation layer I would name the controls that are supposed to represent the business class the same.

I think I could add a suffix like "View", but I want to do it right.

What is the recommend naming conventing for a multi tier application?
How should I name the control that represents the items of a ShoppingCart in the presentation layer?

Edit: Related Questions: How should I name database wrapper object?

Answer 1

In the MVC paradigm, it's fairly common to have Foo, FooView, and FooController.

You might decide it's easier to stick them in a different hierarchy (Shopping.Model.Cart, Shopping.View.Cart). It's conceptually clean, but I think it's rather unreadable. You can use distinct names in different namespaces instead (Shopping.View.CartView).

A good IDE will let you move/rename things, though, so it's not worth spending too much time worrying over picking the perfect name for something. It's more important to be very clear on what you're modeling and what its limitations are. For example...

• Is Car an instance of a car or a particular make/model of car? Is a motorcycle a car? If you're going to rename it to Vehicle, is a bicycle a vehicle?
• Is an Item a type of item, an instance of the item, or quantity instances of the item?
• Is ShoppingCart just a list of items/quantities, or does it have other features? Does it merge duplicates of an item by summing the quantity?
• Is a wishlist a special kind of shopping cart (one you haven't bought yet), or something else?
• Can you "save" a shopping cart and get a quote (so you can print it out, take it to your boss, get it signed off, and then buy it)? Where is the quote stored?

Answer 2

Other StackOverflow folks may know better, but as far as I know, there's no commonly-accepted or industry-standard naming convention relating to tiered architecture. Though I think you're on the right track: moreso than the specific naming, choosing an approach and using it consistently will help make your code more maintainable.

Answer 3

You can use namespace to separate your shopping cart UI and business entity, example:

• YourApp.Web.UI.ShoppingCart (Your shopping cart web control)
• YourApp.BusinessEntity.ShoppingCart (Your shopping cart class in your business logic layer)

When you create/use a shopping cart object, it might not be obvious at first look whether the object is a UI control or an entity class, but your IDE (visual studio) will provide you intellisense when you are writing code and a tooltip when you mouseover the name which can ease your problem.

Alternatively, if you really want to ease your eyes for reading, you can use prefix when naming your object:

• YourApp.Web.UI.ShoppingCart uiShoppingCart;
• YourApp.BusinessEntity.ShoppingCart beShoppingCart;