The Biz Layer Only handles Business logic, nothing more, noting less. It doesn't know or care where the data came from or where it's going, it only cares about manipulating the data to comply with business rules, this would include date validation, data filtering, and data processing.
Validation: This can include checking to see if the data in an entity conforms to business rules, if the request from the UI is valid
in this case the username and password must both have something other then spaces. This could also include a validation api to handle validation requests from the UI, this way you can have consistent validation for every type app that might use it(win forum, win service, website, etc.) .
- Data Filtering: For the most part this is telling the DAL what data it needs, let the DAL figure out how to get it, an example of this would be if you have a collection of accounts and an account must have specific privileges to have access to some data then only request the data for the accounts in the collection that have these privileges
- Data processing: Basically any processing that is based on business rules. This can be as simple as requesting more data based on business rules to parsing text, like a log file, to get specific data, etc. One major advantage of doing N-Tier is if you have an application that is very process intensive it’s easy to scale out using something like wcf or old school web services and move all or part of your business layer to a farm and scale as much as you need from there.
This way you don’t need a bunch of beefy boxes for web servers, this is also nice if your setting this up as a client server app. If done right, you can use the adaptor pattern to spread your application to completely different servers. The point is to isolate functionality in your application, this makes it easy to test, maintain, and update.