Entity Framework and Business Logic

Posted on 2010-01-07
Last Modified: 2013-11-08
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#...
Question by:pipelineconsulting
    1 Comment
    LVL 41

    Accepted Solution

    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)


    Featured Post

    What Should I Do With This Threat Intelligence?

    Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

    Join & Write a Comment

    Welcome my friends to the second instalment and follow-up to our Minify and Concatenate Your Scripts and Stylesheets (…
    Creating an analog clock UserControl seems fairly straight forward.  It is, after all, essentially just a circle with several lines in it!  Two common approaches for rendering an analog clock typically involve either manually calculating points with…
    Internet Business Fax to Email Made Easy - With eFax Corporate (, you'll receive a dedicated online fax number, which is used the same way as a typical analog fax number. You'll receive secure faxes in your email, fr…
    In this seventh video of the Xpdf series, we discuss and demonstrate the PDFfonts utility, which lists all the fonts used in a PDF file. It does this via a command line interface, making it suitable for use in programs, scripts, batch files — any pl…

    729 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    21 Experts available now in Live!

    Get 1:1 Help Now