Last post Mar 08, 2011 04:09 PM by atconway
Mar 08, 2011 03:42 AM|satheeshmenon|LINK
I am developing an ASP.Net application. Intially I planned a 3-tier architecture for the application with a presentation layer, business layer and data access layer. There were seperate classes for each page in these 3 levels. Also there was an additional
class for defining the entities. Stored procedures are used to get records from database. I have used the technique to fetch 10 records at a time using these SP while filling a grid as I thought this would reduce the load on the server when several users try
to access huge amount of records at a time.
I would like to know whether switching to 2 tier architecture would improve the effeciency of the page or rather reduce the load time. In this case I plan to remove the BL and use DAL to directly provide data to the PL. I came to know that several web applications
involving huge amount of data use 2-tier to reduce load time.
Please advice me on the use of 2-tier to improve performance and also any drawbacks if I fetch the entire records to the grid and then use the buil-in paging system. The bottom line is to improve the performance and speed of the page loads/updates.
Mar 08, 2011 03:49 AM|XIII|LINK
I think you're mixing up 2 things: tiers are not the same like layers. You can have 2 tiers for example but 4 layers. A layer's an abstraction in your project, mostly done by using different projects (web project + different class library projects). Tiers
are physical separations between different machines (for example the webserver and the database server).
Most applications that I see being created use multiple layers (web + service + business + persistence) where the software's being put on a webserver and the database on a dedicated machine for the SQL Server.
When things are in memory, meaning just your code that runs all inside the same context of your web application (thus the service + business + persistence) that mostly includes no overhead. The real performance deals are mostly in how you retrieve and handle
your data (not too much, put indexes where needed, ...).
So to get to your problem: if you don't need a business layer in your application then you can leave it out. If you expect that one will be needed in the future you can simply put it in with practically no overhead as it runs in memory (=fast).
Mar 08, 2011 03:59 AM|rtpHarry|LINK
I came to know that several web applications involving huge amount of data use 2-tier to reduce load time.
This seems strange to me, the main benefit is separating your code to keep it well structured. Your bottom data layer deals only with pulling data out of the database. The business logic takes that data and applies business rules to it such as vat rates
depending on the date or "you can't book a meeting room on a sunday" etc. Then passes the cleaned up data to the ui layer.
If you are talking about getting significant benefits from collapsing these two layers then you would still need all the code but you save the nanoseconds that it takes to call a method that was keep the two separate before. I can't see it being a major
The bottom line is to improve the performance and speed of the page loads/updates.
The easiest way to get big performance boosts out of your code is to implement caching in your app. Research the caching options before applying other optimisations. And get a proper profiler such as ANTS and run that on your code to find the real bottlenecks
rather than making large changes that are guesses.
Please advice me on the use of 2-tier to improve performance and also any drawbacks if I fetch the entire records to the grid and then use the built-in paging system. The bottom line is to improve the performance and speed of the page loads/updates.
Careful with this. The simplest "just tick this box for paging" solution selects the ENTIRE table and then throws away any records it doesn't need. This is a massive waste of resources for large tables. You can set up proper paging though as long as you
modify it to use custom paging and handle the page size and current page yourself:
Mar 08, 2011 05:12 AM|satheeshmenon|LINK
Thanks for the advices. I will briefly explain what I have done. I have 4 classes defined for a page, an aspx.cs class for the page, a BL class that defines the functions, a DAL class that gets/saves records from DB and an entity class that defines the entities
relating to the page. Entities are just the field definitions of the tables used and a MapData function to load the entities with values from DataTable. For eg: a table with 2 fields for PK and name would have entities defined us i_id as int and u_name as
string. After getting the records from DAL class in the form of a DataTable, the related function in BL class calls a MapData function in the entity class that assigns the values from the DataTable rows to respective entities based on the fields of the DataTable.
In the aspx.cs class, the function that originally calls to get records, will create an object of the entity class and will retrieve the values of respective entities from this object and assign it to the related controls. I have pasted a sample code below:
objWhySmBL = new WhySmBL();
//To get records from DB through DAL and pass to the entity object
EntWhySM objEntWhySM = objWhySmBL.GetWhySMByID(iID);
if (objEntWhySM != null)
txtFeature.Text = objEntWhySM.u_whysm.Trim();
WhySmID = objEntWhySM.i_whysmid;
The second line calls the BL function to get records and results are loaded to the entity object. Later from this object records are assigned to controls. My another concern is, instead of directly getting records from DataTable, I am using a MapData function
in the entity class that loops the DataTable rows and assigns values to the entities from where it is set to the controls.
Kindly advice me on these techniques and whether they will have any adverse affect on the performance, as it is travelling through different classes. The concept is pretty much similar to one in http://www.dotnetfunda.com/articles/article18.aspx
Mar 08, 2011 08:24 AM|XIII|LINK
most of it is indeed straight forward. I'm just wondering why you wouldn't use an ORM like NHibernate, Entity framework or Linq To Sql. They provide you with the means to hide all the mapping for you instead of looping through datatables etc. I would also
do the mapping in the persistence layer and return List<SomePOCO> to the business layer. Dealing with data's persistence layer specific, in other layers you simply want to work with poco's which have business meaning.
Mar 08, 2011 04:09 PM|atconway|LINK
Everything has been explained well previously, but the following (2) blog posts by Rocky Lhotka help explain well the difference between physical and logical tiers and when applicable:
Should all apps be n-tier?
A variety of physical n-tier options: