Business Layer

The Business Rule Layer
 
The business rule layer is the glue between the user interface layer and the database layer.  It is often the most difficult layer to design.  As a general rule, you'll want to break this up into at least two different areas:  high level and low level.
The high level area is dependent upon the environment of the user interface and is exposed publicly to the user interface.  It will need to have knowledge of or references to user interface controls.  Its usefullness really shows itself when you have multiple applications running in the same operating system environment which share the same data access layer.  This area has the highest likelihood for code duplication because the user interface controls are different for each environment.
For example, if you have a method that should iterate through a grid and save data, the grid control in an ASP.NET application isn't suitable for use in a .NET Windows Forms application that uses a windows DataGrid in a similar UI process.  As you are writing these types of methods, look for ways to push non-environment specific logic down to the low level area to reduce the total amount of duplication.  It is ok to call database access layer methods directly from the high level area.
The low level area (ProductA.BusinessLogic.dll below) should not have any knowledge of or dependencies on user interface controls or objects.  Anytime a high level area method needs to call a low level area method, it should pass control values as standard .NET object types as parameter values.  For example, you wouldn't pass a ListView.Item as a parameter to a low level area method.  You'd pass the value of the ListView.Item as a string, int, double etc... instead.  The low level area is where "most" database access layer calls will be initiated from.  You need to make a decision on a class by class and method by method basis as to whether you want them exposed to the user interface layer.  Typically, you'll want to hide everything from that layer that it doesn't need to see or that you don't want it to call directly.  This reduces confusion for the user interface developers.
In most cases, I like to have most of my business layer methods set as static (Shared in VB.NET) or implemented via a singleton pattern.  There is no real reason ask the framework to load multiple instances of these at runtime.  If you have methods and classes that get used rarely, then not setting them as static is fine and may be preferrable.
 
1. ProductA.BusinessLogic.dll
 (References:  ProductA.DataClasses.dll,ProductA.Shared.dll,ProductA.DataBase.DataAccess.dll,ProductA.DataBase.dll)
 Low level business logic area.
 
2. ProductA.Desktop.dll (Used with a .NET Windows Forms Application - if applicable)
 (References:  ProductA.Shared.dll,ProductA.BusinessLogic.dll, ProductA.DataClasses.dll, ProductA.DataBase.DataAccess.dll, ProductA.DataBase.dll)
 High level business logic area.
 
3. ProductA.DesktopMobile.dll (Used with a .NET Compact Framework Application - if applicable)
 (References:  ProductA.Shared.dll,ProductA.BusinessLogic.dll, ProductA.DataClasses.dll,ProductA.DataBase.DataAccess.dll, ProductA.DataBase.dll)
 High level business logic area.
 
4. ProductA.Web.dll (Used with a ASP.NET Application - if applicable)
 (References:  ProductA.Shared.dll,ProductA.BusinessLogic.dll, ProductA.DataClasses.dll, ProductA.DataBase.DataAccess.dll, ProductA.DataBase.dll)
 High level business logic area.
 One item of interest here.  I work a lot with software families that share analytical data back forth between the desktop and the web.  In some instances, we even replicate what data would look like if it existed on the web via our desktop applications.  Eliminates the need for desktop users to send data up to the web, store it, then log onto the web site and view the data in order to ensure it gets rendered correctly.  If you do this sort of thing, you'll want to consider adding methods in this layer to render pieces of pages and return the results either to the .aspx code behind class or send the rendered portion back to the desktop over .NET Web Services.  The point is, give a lot of thought as to where you put your code before writing the first line even for things as simple as rendereing an html table.

Refer the following articles:

1.http://www.asp.net/learn/data-access/tutorial-02-vb.aspx
2.http://www.codersource.net/Programming_Application_Architecture_azam.aspx