Naming Convention for ASP.NET BAL/DAL?

Discussion in 'ASP .Net' started by dm1608, Feb 23, 2006.

  1. dm1608

    dm1608 Guest

    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?
    dm1608, Feb 23, 2006
    #1
    1. Advertising

  2. dm1608

    Mike Guest

    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/
    Mike, Feb 23, 2006
    #2
    1. Advertising

  3. 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
    --
    http://www.openmymind.net/
    http://www.fuelindustries.com/


    "dm1608" <> wrote in message
    news:O4%...
    > 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?
    >
    >
    Karl Seguin [MVP], Feb 23, 2006
    #3
  4. dm1608

    sloan Guest

    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" <> wrote in message
    news:O4%...
    > 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?
    >
    >
    sloan, Feb 23, 2006
    #4
  5. dm1608

    dm1608 Guest

    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:...
    >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
    > --
    > http://www.openmymind.net/
    > http://www.fuelindustries.com/
    >
    >
    > "dm1608" <> wrote in message
    > news:O4%...
    >> 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?
    >>
    >>

    >
    >
    dm1608, Feb 23, 2006
    #5
  6. 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/


    "dm1608" <> wrote in message
    news:...
    > 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:...
    >>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
    >> --
    >> http://www.openmymind.net/
    >> http://www.fuelindustries.com/
    >>
    >>
    >> "dm1608" <> wrote in message
    >> news:O4%...
    >>> 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?
    >>>
    >>>

    >>
    >>

    >
    >
    Karl Seguin [MVP], Feb 23, 2006
    #6
  7. dm1608

    Mike Guest

    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/
    Mike, Feb 24, 2006
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rick

    Which c# naming convention?

    Rick, Jan 19, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    3,772
    Paul Glavich
    Jan 19, 2004
  2. dm1608

    ASP.NET 2.0 BAL/DAL???

    dm1608, Feb 18, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    1,561
    dm1608
    Feb 18, 2006
  3. Buck Turgidson

    JSP Method Naming Convention

    Buck Turgidson, Mar 2, 2004, in forum: Java
    Replies:
    1
    Views:
    1,748
    P.Hill
    Mar 2, 2004
  4. harry
    Replies:
    2
    Views:
    1,184
    harry
    Dec 8, 2004
  5. Roedy Green

    Naming Convention(s)

    Roedy Green, Sep 3, 2005, in forum: Java
    Replies:
    24
    Views:
    966
    Dale King
    Sep 12, 2005
Loading...

Share This Page