Layers and Entities?

Question

(I'm gonna ask 2 question please).

We use 3 layers: Bl , Dal , UI.

We didn't want to build one big BL , DAL for All Objects.

So we created this structure both for Agents and Leads.

Now lets say I should write a method :

public Agent GetAgentByLead(Lead leadObj)
 {
 }

Question #1

Where does this function should reside on : AgentsBL or LeadsBL ?

Question #2

Lets say I want to use Entity Framework.

A query can be :

var activeAgents= context.Agents.Where(c => c.ACTIVE).ToList();

This line can be executed in myPage.aspx.cs file.

so where are the layers here ? Where will context resides ?

I just dont see how EF deals with layers ( like my first question )

Any help please?

Answer 1

A commonly used pattern for this sort of thing is the Repository Pattern, if you google it you will find loads of info, the idea is that you basically make a repository which encapsulates the context so you are never directly using it...

I prefer generic repositories which have the common CRUD methods, but also have something like:

IEnumerable<T> FindAll(IQuery<T> query);

So rather than having to make a unique repository for each object type to do specific queries, such as your GetAgentByLead you wrap that logic into a query and pass that the context, so your queries, repositories and controllers (assuming MVC) are all seperate and dont rely upon each other.

An example query object would be something like:

public interface IQuery<T>
{
    IEnumerable<T> Execute(IContext context);
}

public class FindAllUsersInGroupQuery : IQuery<User>
{
    public int GroupId {get; set;}

    IEnumerable<User> Execute(IContext context)
    {
        return context.DoSomeQueryForGettingUsers(GroupId);
    }
}

This way you can mock out your queries, repositories and test your controller if you wanted to, also you dont end up with HUGE data accessor classes which are hard to maintain.

Answer 2

1) This is a self-created problem, it's not a customary or good idea to have a DAL for each entity. But assuming they're so big you want to split them, I'd say GetAgentForSomething() belongs in the AgentsDAL. And that will then have a dependency on Leads. You'll have to watch out for circular dependencies here, you may have to define separate DAO and Domain classes.

2) context.Agents.Where(...) is circumventing the layering. Consider AgentsDAL.GetActiveAgents()