Question : Entity Framework and Business Logic

I am a bit confused by the Entity Framework, to which I am new.

I am currently writing a web business application in .NET which is running from a standard SQL database. It is quite a complicated database and has around 60 tables, of which 40 contain "proper" data and the remainder are intermediate tables used for relationships and so on.  It also has stored procedures for doing anything that needs doing to the database (updates, inserts etc.).  

Doing anything like this, I would normally start off with a DAL based on a DataSet and put in all the relevant tables from the database and the relationships etc.  I would then code a business logic layer which taps into the DAL.  Depending on what kind of app it is, I would then have a cache layer which is identical in structure to the BLL - this cache layer is using SQL cache dependencies.   My application then interrogates the cache layer which sets things off down the cache/BLL/DAL/database chain.

I have started to code a set of business objects for use in the app. For each kind of object (e.g. a customer) there are actually two classes - a class representing the business object itself (e.g. for a customer, this is where the name, address and so on are contained).  The second class is a collection which contains items for the object (e.g. a customers collection populated by customers).

Relationships are built into the business object class, so a customer class has a "orders collection" property and so on.  The business object class also contains some more complicated logic, so for an order object class, there may well be methods that raise invoices and so on.

Having got so far, this is fast becoming tedious and unwieldly.  For this reason I was taking an interest in Entity Framework but I am unsure as to how to proceed with this.

1.  Does the entity framework simply replace my DataSet DAL?  
2. If so, where does my business logic (e.g. checking fields before sending to the DB) appear?
3. At the moment, the DAL has methods based on stored procedures - how can I maintain this kind of approach? I want as much data access code in stored procedures as possible and not be querying the database using LINQ in my app classes.
4. Where can I put the more complicated methods that I might have in my business objects?
5. How do I cache the data?
6. What is a POCO and how does this fit into the layering?

Ideally, I want to be in a situation where my UI layer can use nice, friendly, strongly-typed objects and avoid LINQ wherever possible.

Just to throw a potential spanner in the works, I am using VB not C#...

Answer : Entity Framework and Business Logic

Let me take a stab at this....   the current version of the Entity Framework is very database-centric.  Meaning that it must start with a database... rather than start the designer with Entities and then move to the database.   So, quite frankly that's not a big "plus" in my book... as, in my opinion, any good Business Logic Layer (BLL) should be concentrating more on the entities and less on the database

So, what the Entity Framework will do... is get you started with your BLL.  It initially will be populated with the properties that have corresponding database fields.   That means you'll have to pick up where they left off, and add the "Business Logic" in the Business Logic Layer.  You should also include any relevant methods (such as Hire(), Promote(), Fire(), Transfer(), Detail(), etc...using a Employee business object as an example)

1. So, it can't totaly replace your BLL, but it can be a good starting point for a BLL 
2. You'll have to write the business logic yourself... so no time saving there 
3. Yes, your Entities can (and should) use SPs 
4. I'd recommend you keep all of the BLL stuff together, just by extending the Entity classes (perhaps as a separate Partial Class?) 
5. I normally don't cache Entities (other than the collections that are returned via the DAL)... so I can't advise you here 
6. Plain Old CLR Object (POCO) is at the other end of the spectrum... where you just just ADO.Net as your BLL (not recommended)