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

[Big George]

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.

 

[Cowboy \(Gregory A Beamer\)]

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]

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