Naming conventions for Business Layer classes

by the3factory 5/2/2008 9:30:00 PM

Question:

With regards to the article on creating a Business Layer (BLL)

http://www.asp.net/learn/dataaccess/tutorial02cs.aspx?tabid=63

and the naming guidelines suggested in the "Framework Design Guidelines" book, I was wondering if naming a class with a postfix of "BLL" is a proper thing to do? Shouldn't a class in the business layer just be called "Products" instead of "ProductsBLL"?

Any thoughts on this?

Answer1:

I would think that instead of naming it ProductsBLL, name it ProductsLogic. What I am trying to say is that it really won't matter what you name your classes in a particular layer. The only thing is, do remember to be consistent.

Answer2:

I prefer to use the namespace to define the category of object in question. Typically I'll store business objects in a base namespace like:

MyCompany.MyProject

I'll store the data layer classes in something like:

MyCompany.MyProject.Data

For instance:

MyCompany.MyProject.Customer
MyCompany.MyProject.Data.CustomerData

One might even suggest removing the "Data" part of the CustomerData class, but the naming conflicts that causes are usually more trouble than they're worth.

Answer3:

Instead of using class names you should be using namespaces as mentioned above. We use

Company.Project.Business

Company.Project.Site

Company.Project.ContentImporter

etc

I also try to avoid class name clashes by naming the web forms something like ViewProduct.aspx and ListProducts.aspx. Namespaces avoid this but in practise it becomes a little nightmarish when they clash and you end up having to prefix all your business logic with namespace qualifiiers.

Answer4:

I haven't seen the video but a quick note...

Answer5:

An added note on another comment made in the book regards the number of assemblies used and the relative sizes of each one. It is stated that using larger assemblies with more code in them is better than using a large number of smaller assemblies, since each assembly is subject for remapping within a processes working set when loaded separately. Of course, common sense must be used to avoid having large assemblies containing code that should not be together in the same package for deployment, semantic, or other reasons.

In general, I have gone to a structure where I have two or three common base framework assemblies (one for common utilities, abstract factory implementations, and definitions ([some meaningful name].Common), one for base data access classes ([SMN].Data), and one for base user interface classes and model ([SMN].Web or [SMN].Windows/WinForms/WPF).

After this, I have one or two assemblies per major function area (e.g., blogging, customer management, accounting, whatever-general-stuff-app-does, etc.). One or two depends on whether I expect multiple versions of the app (web and windows smart client) or if there will be a separate web service interface to the entire function area. In those cases, I separate the business logic component (usually just named [SM Namespace].Accounting or [SM Namespace].CRM with no BLL or anything) from a component that might define custom server controls or web parts specific to that area of function ([SM Namespace].Accounting.Web as an example).

I have tried multiple structures from monolithic ones where there is one assembly for everything to decomposing features, functions, tiers, and platforms to the point that I had at minimum three assemblies for everything done on a site (e.g., [SMN].Data, [SMN].Domain, [SMN].Presentation, etc.). The structure I described in the last paragraph seems to be the happy medium.

I am interested in comments or alternative opinions, however.

Answer6:

noalt:

Answer7:

Hi,
I am working on a product that has grown quite a bit, but is not yet live. I'm having naming convention worries!

My project structure is
<CompanyName>.<ProductName>.Entities
For the classes that hold the entity data such as Product, which would map to the ProductInfo class .
<CompanyName>.<ProductName>.Web
The Website
<CompanyName>.<ProductName>.Services
For the data access and fairly small amount of business logic. So
<CompanyName>.<ProductName>.Services.Product contains all the logic inserting, updating, retrieving products.

I'm now thinking this is a bad name for this layer. It started as the data layer with a bit of business logic. In my next bit of work, the business logic for an insert of a product will grow quite a bit. In this instance I need async calls to process data, send emails etc. I'm beginning to think this shouldn't be in a layer that is primarily data access. Should I abstract this out so that all direct and simple data access is performed through <CompanyName>.<ProductName>.Data and then business logic through <CompanyName>.<ProductName>.Services?
Thanks for your guidance!

Answer8:

I vote for namespaces. You can always write BusinessLogic.Product instead of ProductBLL or Data.Product instead of ProductData, it looks better and cleaner for me.

M

Answer9:

If you have longer namespaces like CompanyName.ApplicationName.BusinessLogic.Product. You can put a using declaration for just part of the namespace like

using CompanyName.ApplicationName;
and then you can just refer to it as BusinessLogic.Product. However, when you hit tab to auto-complete with intellisense it will put the entire namespace, so you will have a lot of code that looksl ike
BusinessLogic.Product product = new CompanyName.ApplicationName.BusinessLogic.Product();

Answer10:
I agree with using a namespace. I currently like:
CompanyName.ProjectName.DataAccessTier
CompanyName.ProjectName.DataAccessTier.Entities
CompanyName.ProjectName.BusinessTier
CompanyName.ProjectName.PresentationTier
I found this article somewhat relevant to your question http://www.15seconds.com/issue/030602.htm