Naming Convention for ASP.NET BAL/DAL?

[dm1608]

I'm relatively new to ASP.NET 2.0 and am struggling with trying to find the
best naming convention for the BAL and DAL objects within my database. Does
anyone have any recommendations or best practices for naming my objects?

I currently have all my type classses simply called "JobSummaryClass" or
"JobDetailsClass". These classes simply contain the public properties and
the get/set functions for the object. Is this an appropriate naming
convention?

I then have a BAL class that I call simply JobSummaryComponent that contains
all my BAL logic for the various classes.

Finally, I have a DAL class that I call "JobSummary" that contains my DAL.

It seems that my naming convention doesn't really represent whether its a
BAL or DAL and I'm just wondernig if I'm doing this the best way. My
current BAL for JobSummaryComponent contains the code for querying and using
the JobSummaryClass and JobDetailsClass above. So my thought of calling
this BAL JobSummaryComponent shoudl probably be renamed simply to
JobComponentBAL or something.

Also, should I create a separate source file per object or try and put all
related objects/classes within same source??

Opinions?

 

[Mike]

Look to Microsoft's API for guidance. They also publish some standards
documentation.

http://msdn.microsoft.com/library/d...y/en-us/vsent7/html/vxconcodingtechniques.asp

Here are some of my rules:

1)Don't suffix a class with "Class", don't prefix it with "C" either.
You don't need to add anything to the name of a class to denote that it
is a class, struct or enum.

2) Always use Pascal casing on classes, methods, properties, and
events.

3) Use camel casing on class fields, and parameters to methods. Many
people also prefix or suffix fields with an underscore "_" to
differentiate them from method parameters.

4) When a method parameter is used to set or represent a given class
property, name it the same as that class property, but still with camel
casing.

5) don't prefix fields or properties with hungarian notation "str" for
string, "int" for integer,etc... The name of the field/property should
denote what it is implicitely. For instance FirstName is obviously a
string.

6) local method variables in a method should be named according to what
they are used for, and may include a type prefix, especially when the
same logical information needs to be stored as two types.

If you want to see these general rules in action, see the public API
for my components at the following link. There are also code examples
in some of the help that shows the private member rules.

http://www.xquisoft.com/xqsdn/documentation/index.html
http://www.xquisoft.com/xqsdn/documentation/xquisoft.data.datamanager.html

In general you should just look at a bunch of other peoples code. Find
a style that makes sense to you, and that seems relatively common.
That is how I came up with the rules above. The .net framework is was
a good starting point.

A google search on "C# coding standards" has alot of helpful links.

Michael Lang
XQuiSoft LLC
http://www.xquisoft.com/

 

[Karl Seguin [MVP]]

I don't like the use of the word "class". Why don't you want to merge your
data with your behaviour (which you intentionally seem to not be doing) (ie
merging JobSummaryClass and JobSummaryComponent). There's more debate about
whether your DAL should or shouldn't be merged (I like to merge it).

Assuming you have good reason, I'd probably name them:

JobSummaryData
JobSummary

the name of your DAL isn't all that important since it should be internal
and not part of the exposed API. (your JobSummaryData could also be
internal depending on exactly how your building your stuff).
JobSummaryDataAccess

Karl

 

[sloan]

google "brad abrams"... he has alot of naming conventions stuff.
he is a MS employee.

...

I do this:


(biz)
public class Emp{}
public class EmpCollection{}

(data)
public class EmpData{}

(back in the biz)
public class EmpController{}


Emp is the business object.
EmpCollection is a collection of Emp objects.

EmpData (I put mine in its own assembly) is the data layer object.

EmpController is the business layer object..which returns Emp and
EmpCollection objects... and ~talks to EmpData

full names:

((MyCompany.MyApplication.BusinessLayer (assembly) ))
MyCompany.MyApplication.BusinessLayer.EmpLib.Emp
MyCompany.MyApplication.BusinessLayer.EmpLib.EmpCollection
MyCompany.MyApplication.BusinessLayer.Controllers.EmpController

(I put my controllers in 1 namespace..just a preference I have..
MyCompany.MyApplication.BusinessLayer.EmpLib.EmpController might be good
too)
....
((MyCompany.MyApplication.Data (assembly))
MyCompany.MyApplication.Data.EmpDataLib.EmpData

...

I also put my DataSets (strong typed) outside of these assemblies

MyCompany.MyApplication.Data.DataSets.EmpDSLib.EmpDS
(if I need them...sometimes I don't need DataSets..it depends... I usually
use them in a web app, more than a winforms app)

...

I put Framework pieces in

MyCompany.Data

or
MyCompany.Framework.UIFramework (as an example)

framework pieces are the common code.. that lives "above" and outside any
application specific code.

...

 

[dm1608]

Thanks --

I thought that the standard was not to merge the BAL and DAL simply so I
could re-use either, if needed, for another project??

I like your idea about JobSummaryData. I thought JobSummaryDataAccess
seemed a bit long and blantently "Newbie" approach.


"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> wrote in message news:[email protected]...

 

[Karl Seguin [MVP]]

Yes, different people feel differently about integrating the data access
layer...but your properties SHOULD be merged with your methods...I don't
think there's many people who feel otherwise.

I normally keep my DAL separate, but only exposable through methods in my
class.

for example, I like to do

//in my User class
public static int GetUserById(int userId)
{
//use dal to access store
}

many people prefer not to have this in the same class, which si fine, but
your presentation layer shouldn't be talking directly to your DAL. It should
go through a business layer, whether tha'ts the core class or some component
class doesn't really matter. This way you can implement business rules
/functions inside these methods.

Karl

--
http://www.openmymind.net/
http://www.fuelindustries.com/

Thanks --

I thought that the standard was not to merge the BAL and DAL simply so I
could re-use either, if needed, for another project??

I like your idea about JobSummaryData. I thought JobSummaryDataAccess
seemed a bit long and blantently "Newbie" approach.


"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> wrote in message news:[email protected]...

 

[Mike]

You and Karl both have good points. There are multiple design patterns
you can follow in separation of application layers. I've listed a few
of them in an earlier post for another thread. See the following link:

my message only:
http://groups.google.com/group/microsoft.public.dotnet.framework.adonet/msg/5f9aa84c94991171?hl=en&
whole thread:
http://groups.google.com/group/micr...321c/5f9aa84c94991171?&hl=en#5f9aa84c94991171

As I noted in the other message, make sure you are not separating
layers of an application just for the sake of doing so. You shouldn't
blindly follow a pattern because others say it is good. You need to
fully understand why you are following the pattern, otherwise you'll
miss the point and do it incorrectly.

What is going to be reused from your data layer by another application?
Data layers are generally customized to return data in a particular
format for a single application. The reason you usually separate
layers is for "encapsulation". You may need to change the database or
database structure used by a large application. If you designed your
application correctly, you should only have to change the data layer of
the application. Since potentially multiple business layer functions /
rules may depend on the same data layer calls, this reduces the amount
of code to be changed.

This brings me to another point. Return application domain specific
class types from your data layer. If you return a DataSet, and it is
returned up to the UI, you'll be in trouble if the database structure
is updated because those changes will affect the DataGrid or other UI
elements or code behind. This is where it can get complex. If your
entities are defined in the business layer, how can the data layer
return those types without causing a circular reference?

There are a few primary solutions. These are similar to the patterns
in the above referenced post.

1) create a separate component to define entities otherwise known as
data containers. There are just classes with properties for each data
element. Then both the business and data layer can reference them.
The data layer can use data readers to fill entities and pass them to
the BAL. The BAL can do any additional rule processing and pass them
to the UI.

2) The BAL and DAL can be one. Put your Load, Save, and Delete methods
on your "entities" which do the necassary database calls. This
encapsulates your DAL access into individual methods. It sounds like
this is what Karl uses.

3) use the provider pattern. define entities in the "BAL". Also
define the contract classes that define the data operations you need.
Create a separate DAL that implements those contract classes. As I
said in the other post, this is the pattern that both Microsoft and I
favor.

I say Microsoft favors the provider pattern because they use it
throughout .NET 2.0, such as in their membership system:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp04212004.asp

I also use it here:
http://www.xquisoft.com/xqsdn/documentation/index.html
http://www.xquisoft.com/xqsdn/documentation/xquisoft.data.datamanager.html

Michael Lang
XQuiSoft LLC
http://www/xquisoft.com/