Description of BLL

Within a BLL objects can further be partitioned into business processes (business activities) and business entities. Business process objects typically implement the controller pattern, i.e. they contain no data elements but have methods that orchestrate interaction among business entities. Business entities typically correspond to entities in the logical domain model, rather than the physical database model. Domain entities are a super-set of data layer entities or data transfer objects, and may aggregate zero or more Dies/DTOs.

http://en.wikipedia.org/wiki/Business_layer

[I]n many cases [the BLL is] just the bridge in between the presentation layer and the data access layer with having nothing much, except taking from one and passing to the other... The business entities should meaningfully define considering various types of requirements and functioning of your system. It is recommended to identify the business entities to encapsulate the functional/ UI (User Interface) requirements of your application, rather than define a separate business entity for each table of your database.

http://www.codeproject.com/Articles/22769/Introduction-to-Object-Oriented-Programming-Concep#three-tier

Business Rule Layer
This layer is implemented in order to encapsulate your business rules. If you have followed best practices, you will have created a set of documents which describe your business. In the best of cases, you will have a set of use-cases describing your business in precise detail. From this you will have been able to create a class association diagram which will help you create your business layer.

Here we find classes which implement your business functionality. They neither access data (except through the data layer) nor do they bother with the display or presentation of this data to the user. All we are interested in at this point are the complexities of the business itself. By isolating this functionality, we are able to concentrate on the guts of our system without the worry of design, workflow, or database access and related concurrency problems. If the business changes, only the business layer is affected, again considerably simplifying future maintenance and/or enhancements.

http://www.dotnetspider.com/forum/166048-use-n-tier-architechture.aspx

It's also worth emphasizing that putting behavior into the domain objects should not contradict the solid approach of using layering to separate domain logic from such things as persistence and presentation responsibilities. The logic that should be in a domain object is domain logic - validations, calculations, business rules - whatever you like to call it.

http://martinfowler.com/bliki/AnemicDomainModel.html

  In the very center we see the Domain Model, which represents the state and behavior combination that models truth for the organization. ... the Domain Model is only coupled to itself.

  http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

[W]e have decided that Castle Validators are a natural fit for validating data integrity of the EditModel (the type being bound by the model binder when a form is submitted to a controller action).  This is not business rule validation.  This is merely things like: “can the characters that were submitted be parsed into a date, an int, a guid”, etc.  Once we get passed data type validation, then the domain model can work on the more interesting business rules.

 http://jeffreypalermo.com/blog/you-should-not-use-asp.net-mvc-if/

Business logic is the if statements and the loops and the stuff that actually does work...

Miško Hevery - http://www.youtube.com/watch?v=wEhu57pih5w

This offers an excellent benefits in real word scenarios where you have certain methods on an entity that return an IQueryable of T and some methods return List<T>. But then you have business rule filter that needs to be applied on all the collection regardless if the collection is returned as IQueryable of T or IEnumerable of T. From a performance stand point, you really want to leverage executing the business filter on the database if the collection implements IQueryable otherwise fall back to apply the business filter in memory using Linq to object implementation of delegates.

http://weblogs.asp.net/zeeshanhirani/archive/2008/07/31/using-asqueryable-with-linq-to-objects-and-linq-to-sql.aspx

The presentation (that is, the codebehind or controller class) references the application logic, namely a component that implements the application’s use cases. The application logic technically belongs to the business layer or tier, and in very simple cases may be merged with the presentation. This is what happens in some tutorials that are either too simple to really feel the need for isolating application logic in its own layer, or poorly designed and splitting application logic between the presentation and the data access layer (DAL).
 
The application logic orchestrates the DAL, domain classes and services to pursue the expected behavior. The application logic communicates with the presentation layer through view model objects and communicates with the DAL through domain objects. The DAL, in turn, references the model and the ORM assembly.

 http://msdn.microsoft.com/en-us/magazine/hh456393.aspx

Remember that the business logic in Microsoft Dynamics AX can be used though COM from other applications. For example, an X++ script can access the business logic that creates a sales quotation. This underscores the importance of not letting the business logic be dependent on a specific Microsoft Dynamics AX form or report.

  http://msdn.microsoft.com/en-us/library/aa857073.aspx

In deleting a customer however there are many business logic decisions to be taken. Can the customer be deleted? What are the processes that must be performed before and after? What are safeguards that must be checked first? From which tables the records are to be deleted, or updated as a consequence? ... [re phone numbers] It is important that although it is formatting, it's not user interface, and although the urge for any centralization often ends up in the database, this is clearly business logic. Implementing formatting in the business layer eliminates duplicate data, and allows for implementation using a development language rather than shoe horning it into a data language.

http://www.codeproject.com/Articles/10746/Dude-where-s-my-business-logic