Where to put business logic when using Entity framework and ASP.NET

Typically I have started new projects with a solution containing:
- Web project: contains the mvc, javascript code etc. Makes calls to class library
- Class library1: contains Dbcontext, EF Data model, a class with CRUD methods to interface with Db via the DbContext and various "utility" methods
- Class library2: contains only POCO classes. This library is referenced by both the web project and library1

Ok, that works well, but when the amount of "business logic" starts to increase, this gets kinda messy, since I start putting in more rules that the business gives you. Makes me think there needs another "layer" or library where we put "business logic" that really is above/beyond just getting a data returned as a filtered list of POCO objects. Things such as checking attributes of orders based on some rules defined by some group within the business.

My question then is: Would you force every call from the client layer to go through the business library (see image below case #2), even for simple cases where you just need a simple list of lookup values of some sort?