Best practices to develop a project (.vbproj) in ASP.NET

Discussion in 'ASP .Net' started by Big George, Feb 11, 2009.

  1. Big George

    Big George Guest

    Hello,

    What do you think is the proper way (best practices) to develop a
    project in ASP.NET?

    I mean, how should I structure the .aspx, .vb, .js and .css files in a
    project?

    A solution can have one or multiple projects. I think if the web
    application is going to be big, then it justifies to have several
    projects in a solution.

    But if the web application is medium/small, then a solution can
    contain one project.

    How to structure an asp.net project (.vbproj)?

    By theory, best practices are:

    - Presentation Tier: aspx, Jscript, aspx.vb

    - Business Logic Tier: Business Objects and Rules. Data Manipulation
    and Transformation into Information

    - Data Access Tier: Interfaces with the Database. Handles all Data I/
    O. Made to scale, usually stateless

    - Data Tier: Storage. Query & storage optimization. Performance
    (indexing, etc)

    A question that I have is: "Business Logic Tier" has to be a different
    namespace? "Data Access Tier" has to be a different namespace?

    This Solution Explorer structure is well developed?

    - Solution_Name
    - Project_Name
    My Project
    App_Data
    + images
    + temp
    + BL
    BL_Class_1.vb
    BL_Class_2.vb
    BL_Class_3.vb
    + DA
    DA_Class_1.vb
    DA_Class_2.vb
    DA_Class_3.vb
    + Styles
    css_1.css
    css_2.css
    Default.aspx
    Web.Config
    WebForm_1.aspx
    WebForm_2.aspx
    WebForm_3.aspx
    WebForm_4.aspx

    And now, how to structure my Business and DataAccess classes?

    - For every webform, should I have one BL and one DA class?
    Like: WebForm_1.aspx <-> Class_BL_1.vb <-> Class_DA_1.vb

    - Should my BL and DA classes be abstract concepts?
    Like: Customer_BL.vb, Payroll_DA.vb, Banks_BL.vb and WebForm_1.aspx,
    WebForm_2.aspx, etc

    - In some projects I have seen: for each database table, there is a BL
    and DA class.
    Like: database_Table_1 <-> Class_BL_1 <-> Class_DA_1
    Is that a proper way to develop classes?

    Thank you very much.
    Big George, Feb 11, 2009
    #1
    1. Advertising

  2. "Big George" <> wrote in message
    news:...
    > Hello,
    >
    > What do you think is the proper way (best practices) to develop a
    > project in ASP.NET?


    Build the application without ASP.NET in mind. Think through the
    funcationality and build it outside ASP.NET. YOu then add ASP.NET as a user
    interface. Thinking this way makes the site more testable, more maintainable
    and easily allows you to switch UI technologies without a rewrite.

    > I mean, how should I structure the .aspx, .vb, .js and .css files in a
    > project?


    I tend to think of the UI in terms of usage. For ASPX, this might mean:

    <root>
    Admin
    Company
    Contact

    The actual grouping is less important than just making sure you have things
    in bite sized chunks.

    For .js and .css, it really depends on where you are going. For a non-themed
    site, something like

    <root>
    css
    js

    is fine. With themes, you end up repeating the structure for each theme.

    > A solution can have one or multiple projects. I think if the web
    > application is going to be big, then it justifies to have several
    > projects in a solution.


    I disagree. I think it always warrants more than one solution unless you are
    absolutely sure it is only a prototype or a very short term application.
    Even then, I think you should make sure you can justify shoving code into
    your ASPX before going that route.

    > But if the web application is medium/small, then a solution can
    > contain one project.


    Size is not the proper deciding point. Better questions are:

    1. Is this application mission critical?
    2. Will this application be used for long?
    3. Is there any complex logic?
    4. Is the database rock solid or is there critical logic in the application?

    3 and 4 are aimed more for testability, which is very hard in a ASPX
    project/solution, where every bit of code is shoved into a single project.
    The other two are more general, but hit many aspects of development.

    > How to structure an asp.net project (.vbproj)?
    >
    > By theory, best practices are:
    >
    > - Presentation Tier: aspx, Jscript, aspx.vb
    >
    > - Business Logic Tier: Business Objects and Rules. Data Manipulation
    > and Transformation into Information
    >
    > - Data Access Tier: Interfaces with the Database. Handles all Data I/
    > O. Made to scale, usually stateless
    >
    > - Data Tier: Storage. Query & storage optimization. Performance
    > (indexing, etc)
    >
    > A question that I have is: "Business Logic Tier" has to be a different
    > namespace? "Data Access Tier" has to be a different namespace?


    Yes. You can technically get around this, but creating Imports or using
    statements and references are not so difficult you should not name things
    differently.

    I generally use a naming convention like:

    <company>.<project>.<tier>.<purpose>

    If I am in RAD mode, I will often end up with projects named like the
    following:

    MyCorp.EComm.UI.Web
    MyCorp.EComm.Business
    MyCorp.EComm.Data.Objects
    MyCorp.EComm.Data.Access

    It is very obvious where you go to find certain types of code.

    > This Solution Explorer structure is well developed?
    >
    > - Solution_Name
    > - Project_Name
    > My Project
    > App_Data
    > + images
    > + temp
    > + BL
    > BL_Class_1.vb
    > BL_Class_2.vb
    > BL_Class_3.vb
    > + DA
    > DA_Class_1.vb
    > DA_Class_2.vb
    > DA_Class_3.vb
    > + Styles
    > css_1.css
    > css_2.css
    > Default.aspx
    > Web.Config
    > WebForm_1.aspx
    > WebForm_2.aspx
    > WebForm_3.aspx
    > WebForm_4.aspx
    >
    > And now, how to structure my Business and DataAccess classes?


    The folders depend on the size and function. For example, in Data Access,
    you might have something like

    MyCorp.EComm.Data.Access
    Repositories
    Intefaces

    This, of course, is aimed for the Repository pattern.

    > - For every webform, should I have one BL and one DA class?
    > Like: WebForm_1.aspx <-> Class_BL_1.vb <-> Class_DA_1.vb


    This means you are coupling your logic to UI rather than business function
    in most cases. I prefer to get use cases and tailor the business layer
    first. You then match up the UI to the input needed to fulfill the cases.
    Data is a different creature and deals with getting objects, so it is
    generally more focused on the business objects than use cases, although you
    do have to keep the cases in mind.

    What this means is the UI and business will often line up 1 to 1, at least
    on the first business class called by the UI. The data layer, however, will
    widely diverge in most cases. If it is not, you are probably writing as if
    you are in one project, even though you have code separated out.

    > - Should my BL and DA classes be abstract concepts?
    > Like: Customer_BL.vb, Payroll_DA.vb, Banks_BL.vb and WebForm_1.aspx,
    > WebForm_2.aspx, etc


    This really depends on the use cases, but it is certainly quite common to
    have some classes that are more generic and bridge the gap between the data
    way of looking at things and the UI way.

    > - In some projects I have seen: for each database table, there is a BL
    > and DA class.
    > Like: database_Table_1 <-> Class_BL_1 <-> Class_DA_1
    > Is that a proper way to develop classes?


    It works, although you will generally end up with some classes on top
    (closer to the UI) that follow use cases. Otherwise, you are simply writing
    a UI for database access.

    What you have described here, overall, is the Top down (UI first) versus
    Bottom up (database first) development methodologies. And the primary
    question between these is "does my business tier look like the UI or the
    database". I think this is a mistake.

    Get the use cases first. Then identify domain objects (business objects)
    that fulfill the cases. When you get to database design, design for best
    storage or performance, but do not shackle yourself to the domain objects.
    Instead, figure out how you will map them. As for the UI, figure out how
    best to gather information from the user and present information back.

    Done this way, you will find that there are some places where things do not
    jive 100%, but that is okay. You simply add in the mappings.

    You can ignore all of this if this is a project to gather information for a
    few weeks that is going to be pitched. ;-)


    --
    Gregory A. Beamer
    MVP; MCP: +I, SE, SD, DBA

    Blog:
    http://feeds.feedburner.com/GregoryBeamer

    ********************************************
    | Think outside the box! |
    ********************************************
    Cowboy \(Gregory A Beamer\), Feb 12, 2009
    #2
    1. Advertising

  3. Big George

    Big George Guest

    Thank you so much, Gregory, for your ideas and concepts.

    On Feb 12, 8:37 am, "Cowboy \(Gregory A Beamer\)"
    <> wrote:
    > "Big George" <> wrote in message
    >
    > news:...
    >
    > > Hello,

    >
    > > What do you think is the proper way (best practices) to develop a
    > > project in ASP.NET?

    >
    > Build the application without ASP.NET in mind. Think through the
    > funcationality and build it outside ASP.NET. YOu then add ASP.NET as a user
    > interface. Thinking this way makes the site more testable, more maintainable
    > and easily allows you to switch UI technologies without a rewrite.
    >
    > > I mean, how should I structure the .aspx, .vb, .js and .css files in a
    > > project?

    >
    > I tend to think of the UI in terms of usage. For ASPX, this might mean:
    >
    > <root>
    >     Admin
    >     Company
    >     Contact
    >
    > The actual grouping is less important than just making sure you have things
    > in bite sized chunks.
    >
    > For .js and .css, it really depends on where you are going. For a non-themed
    > site, something like
    >
    > <root>
    >     css
    >     js
    >
    > is fine. With themes, you end up repeating the structure for each theme.
    >
    > > A solution can have one or multiple projects. I think if the web
    > > application is going to be big, then it justifies to have several
    > > projects in a solution.

    >
    > I disagree. I think it always warrants more than one solution unless you are
    > absolutely sure it is only a prototype or a very short term application.
    > Even then, I think you should make sure you can justify shoving code into
    > your ASPX before going that route.
    >
    > > But if the web application is medium/small, then a solution can
    > > contain one project.

    >
    > Size is not the proper deciding point. Better questions are:
    >
    > 1. Is this application mission critical?
    > 2. Will this application be used for long?
    > 3. Is there any complex logic?
    > 4. Is the database rock solid or is there critical logic in the application?
    >
    > 3 and 4 are aimed more for testability, which is very hard in a ASPX
    > project/solution, where every bit of code is shoved into a single project..
    > The other two are more general, but hit many aspects of development.
    >
    >
    >
    > > How to structure an asp.net project (.vbproj)?

    >
    > > By theory, best practices are:

    >
    > > - Presentation Tier: aspx, Jscript, aspx.vb

    >
    > > - Business Logic Tier: Business Objects and Rules. Data Manipulation
    > > and Transformation into Information

    >
    > > - Data Access Tier: Interfaces with the Database. Handles all Data I/
    > > O. Made to scale, usually stateless

    >
    > > - Data Tier: Storage. Query & storage optimization. Performance
    > > (indexing, etc)

    >
    > > A question that I have is: "Business Logic Tier" has to be a different
    > > namespace? "Data Access Tier" has to be a different namespace?

    >
    > Yes. You can technically get around this, but creating Imports or using
    > statements and references are not so difficult you should not name things
    > differently.
    >
    > I generally use a naming convention like:
    >
    > <company>.<project>.<tier>.<purpose>
    >
    > If I am in RAD mode, I will often end up with projects named like the
    > following:
    >
    > MyCorp.EComm.UI.Web
    > MyCorp.EComm.Business
    > MyCorp.EComm.Data.Objects
    > MyCorp.EComm.Data.Access
    >
    > It is very obvious where you go to find certain types of code.
    >
    >
    >
    > > This Solution Explorer structure is well developed?

    >
    > > - Solution_Name
    > > -   Project_Name
    > >       My Project
    > >       App_Data
    > >     + images
    > >     + temp
    > >     + BL
    > >          BL_Class_1.vb
    > >        BL_Class_2.vb
    > >        BL_Class_3.vb
    > >     + DA
    > >        DA_Class_1.vb
    > >        DA_Class_2.vb
    > >        DA_Class_3.vb
    > >     + Styles
    > >          css_1.css
    > >          css_2.css
    > >       Default.aspx
    > >       Web.Config
    > >       WebForm_1.aspx
    > >       WebForm_2.aspx
    > >       WebForm_3.aspx
    > >       WebForm_4.aspx

    >
    > > And now, how to structure my Business and DataAccess classes?

    >
    > The folders depend on the size and function. For example, in Data Access,
    > you might have something like
    >
    > MyCorp.EComm.Data.Access
    >     Repositories
    >     Intefaces
    >
    > This, of course, is aimed for the Repository pattern.
    >
    > > - For every webform, should I have one BL and one DA class?
    > > Like: WebForm_1.aspx <-> Class_BL_1.vb <-> Class_DA_1.vb

    >
    > This means you are coupling your logic to UI rather than business function
    > in most cases. I prefer to get use cases and tailor the business layer
    > first. You then match up the UI to the input needed to fulfill the cases.
    > Data is a different creature and deals with getting objects, so it is
    > generally more focused on the business objects than use cases, although you
    > do have to keep the cases in mind.
    >
    > What this means is the UI and business will often line up 1 to 1, at least
    > on the first business class called by the UI. The data layer, however, will
    > widely diverge in most cases. If it is not, you are probably writing as if
    > you are in one project, even though you have code separated out.
    >
    > > - Should my BL and DA classes be abstract concepts?
    > > Like: Customer_BL.vb, Payroll_DA.vb, Banks_BL.vb and WebForm_1.aspx,
    > > WebForm_2.aspx, etc

    >
    > This really depends on the use cases, but it is certainly quite common to
    > have some classes that are more generic and bridge the gap between the data
    > way of looking at things and the UI way.
    >
    > > - In some projects I have seen: for each database table, there is a BL
    > > and DA class.
    > > Like: database_Table_1 <-> Class_BL_1 <-> Class_DA_1
    > > Is that a proper way to develop classes?

    >
    > It works, although you will generally end up with some classes on top
    > (closer to the UI) that follow use cases. Otherwise, you are simply writing
    > a UI for database access.
    >
    > What you have described here, overall, is the Top down (UI first) versus
    > Bottom up (database first) development methodologies. And the primary
    > question between these is "does my business tier look like the UI or the
    > database". I think this is a mistake.
    >
    > Get the use cases first. Then identify domain objects (business objects)
    > that fulfill the cases. When you get to database design, design for best
    > storage or performance, but do not shackle yourself to the domain objects..
    > Instead, figure out how you will map them. As for the UI, figure out how
    > best to gather information from the user and present information back.
    >
    > Done this way, you will find that there are some places where things do not
    > jive 100%, but that is okay. You simply add in the mappings.
    >
    > You can ignore all of this if this is a project to gather information for a
    > few weeks that is going to be pitched. ;-)
    >
    > --
    > Gregory A. Beamer
    > MVP; MCP: +I, SE, SD, DBA
    >
    > Blog:http://feeds.feedburner.com/GregoryBeamer
    >
    > ********************************************
    > |    Think outside the box!                            |
    > ********************************************
    Big George, Feb 16, 2009
    #3
    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. karim
    Replies:
    0
    Views:
    457
    karim
    Jul 13, 2003
  2. Walden Peters

    Convert csproj to vbproj

    Walden Peters, Apr 13, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    3,038
    =?Utf-8?B?RGF2aWQgQW50b24=?=
    Apr 13, 2005
  3. Ken Fine
    Replies:
    2
    Views:
    572
    Guest
    Jun 25, 2005
  4. 1idMonk
    Replies:
    2
    Views:
    13,068
    =?Utf-8?B?Qm9va2VyVw==?=
    Jan 5, 2006
  5. Juergen
    Replies:
    2
    Views:
    7,027
    Juergen
    Jan 20, 2005
Loading...

Share This Page