n-tiers

[trungluu]

Hi All,

I have read in some books about 3-tiers architecture. I know we should seperate the application into tiers (presentation, business logic, data access, and data). Because the presentation does not connect to data access layer directly so in business logic layer, I have to write most methods that I have done on data access layer. Example

=====Data Access=====
/// <summary>
/// gets the name of the project,which has the project id = nProjID
/// </summary>
/// <param name="nProjID"></param>
/// <returns></returns>
public string GetProjectName(int nProjID)
{
string strName;
// Establish Connection
SqlConnection oConnection = GetConnection();

// build the command
SqlCommand oCommand = new SqlCommand("GetProjectName",oConnection);
oCommand.CommandType=CommandType.StoredProcedure;

// Parameters
SqlParameter paraProjID = new SqlParameter("@ProjID",SqlDbType.Int);
paraProjID.Value=nProjID;
oCommand.Parameters.Add(paraProjID);

SqlParameter paraName= new SqlParameter("@Name",SqlDbType.Char,50);
paraName.Direction=ParameterDirection.Output;
oCommand.Parameters.Add(paraName);

try
{
oConnection.Open();
oCommand.ExecuteNonQuery();
strName=(string) paraName.Value;
return strName;
}
catch(Exception oException)
{
throw oException;
}
finally
{
oConnection.Close();
}

}
====Business Logic==============
/// <summary>
///
/// </summary>
/// <param name="nProjID"></param>
/// <returns></returns>
public string GetProjectName(int nProjID)
{
try
{
string strProName;
DAProject oDAProject = new DAProject();
strProName=oDAProject.GetProjectName(nProjID);
return strProName;
}
catch(Exception oException)
{
throw oException;
}

}
=============================
Could you please tell me why don't we connect directly to Data Access layer? just have some methods that need to implement a business rule. We only use business logic class on this case? is it good?

Thanks in advance,

Trung Luu

[Nigh™a®e]

Hi,

U can choose if u use the business logic layer or not.
Mostly n-tier applications are build to run on multiple servers.

I think the difference between the business and datalayer are usefull when using more as 1 insert, update, delete method with different parameters.

For example:
If u work with different user roles, or connect different applications to your business layer, u can give ure business facade methods like

Public overloads Function UpdateProject(ID as long, Name as string, Description as string, Owner as string) as boolen
TODO: Update fileds on dataset
End function

Public overloads function UpdateProject(ID as long, Description as string)
TODO: Fill fields on dataset
End function

u can see here i made a overload method with different parameters. for example the first one is called by the admin tool and can update all fields.

Second method can only update the description.

For the data access component u only need 1 method

Public function UpdateProject(byval data as ProjectData) as Boolean
.....
adapter.update(data,"Tablename")
End Function

So for this kind of work its very usefull.
I guess its allways best to take full usage of the n-tier framework using
BusinessFacade
BusinessRules
Common / Common.Data
DataAccess
SystemFramework

FrontEnd applications (websites, webservices, client applications)
BackOffice applications (like an intranet or user/order management tools, ....)
Application service (i allways use a windows service for the remoting host)

Greetz Nightmare

[MrNorth]

You should encapsulate your DB access into one object. I suggest creating it using the Abstract Pattern Factory. The you only need to call say an DBAccessOledbFactory object if you want to do something with your database from the model(business) layer.

Check out the Model-View-Controller pattern

I suggest you then write a wrapper class around your db factory that enables you to easily manipulate the database with easy-to-use methods, declared as shared(in vb.net). Like GetCustomer, GetCustomerById etc etc

Then it is very easy to access the db, and it will be nicely encapsulated and organized... and according to all the best practicies there are...


kind regards
Henrik

[hellswraith]

Here is the reason I say keep it 3 tiered, and the only reason.

If there is a chance that you are going to have to throw more machine power to run your app in the future, then do three tier upfront.

If you will NEVER be adding more hardware to your app, then why waste the time.

For example:

You have one user that uses an app. The app just has some simple things it does. The task that this user does will never grow to become something others will have to take on and help with. Don't do a three tiered app.

You have a 10 user app. All users use this app on a daily basis to do data entry for a call center or something. Since a call center could expand in the future (the company grows at a exponential rate) and you may see 100 people using the app in 6 years, then having it as a three tiered design will help you. This is because you can seperate every tier on to a new machine each with its own processor and such.

If you do absolutely no/very litte business code in your business layer, then it only serves as another layer, and should be discarded.

You should architect your app based off of the needs of the application.

[MrNorth]

Im not sure if you wrote this reply based on what I answered...

You should architect your app based off of the needs of the application.

When I wrote the answer I assumed it was for an enterprise application (or an app with lots of users, anyway), otherwise there is no apparent need for the pattern and MVC... but I think the dbaccess is always nice to encapsulate... because it is so boring to write over and over again


kind regards
Henrik

[hellswraith]

No, I was just adding my thoughts to the subject. Wasn't discounting anyone elses posts or anything.

If you like to not re-write db access code, check this link:

http://msdn.microsoft.com/library/de...ml/daab-rm.asp

I use it 100% of the time when I am accessing a sql db.

[MrNorth]

Yeah, that is a great component, but because I do 9 out of 10 applications for Oracle 9i I wrote my own wrapper that uses singleton and abstract factory patterns, that encapsulates both the sql and the oledb...


/Henrik

[VBCrazyCoder]

You could always design your application so that it can run on a single machine (all locally) or on several machines (business tier, data tier). I have this set up and I only need to change the client config file to tell the application to run locally or remotely.

It took some time, but well worth it.

[MrNorth]

When speaking of n-tire design, where can I find some easy to understand tutorials on Model-View-Controller? I have some difficulties understanding how to write the controllers and view objects. It involves a lot of event and delegate programming... and I have some problems with that particular area...

kind regards
Henrik