Using repository model in n-tiered application

Question

This is a subject that I have given some thought to and just tried to get a POC working but I am getting a bit lost to be honest.

So I have a 3 tiered web app, the traditional DAL, BAL & FE structure for the purpose of this exercise.

The DAL has reference to my DB through Entity Framework and from this we gain access to a single table JobInfo.

The BAL references the DAL project and has this interface:

public interface IJobInfoRepository
{

    IEnumerable<JobInfo> SelectAll();
    JobInfo SelectByID(string id);
    void Insert(JobInfo obj);
    void Update(JobInfo obj);
    void Delete(string id);
    void Save();     
}

Then I have this class:

public class JobInfoRepository : IJobInfoRepository
{

    public JobInfoRepository()
    {
        _db = new TestEntities();
    }

    public JobInfoRepository(TestEntities db)
    {
        _db = db;
    }

    private TestEntities _db = null;

    public IEnumerable<JobInfo> SelectAll()
    {
        return _db.JobInfoes.ToList();
    }

    public JobInfo SelectByID(string id)
    {
        return _db.JobInfoes.Find(id);
    }

    public void Insert(JobInfo obj)
    {
        _db.JobInfoes.Add(obj);
    }

    public void Update(JobInfo obj)
    {
        _db.Entry(obj).State = EntityState.Modified;
    }

    public void Delete(string id)
    {
        JobInfo existing = _db.JobInfoes.Find(id);
        _db.JobInfoes.Remove(existing);
    }

    public void Save()
    {
        _db.SaveChanges();
    }
}

In my FE project I reference the BAL project. But this is where I'm lost. Without giving FE access to the DAL project and therefore having visibility to my JobInfo entity how can the FE code perform any of the CRUD operations in the BAL project?

Thanks,

Dave

score 1 · Answer 1 · edited Jun 15 '14 at 16:04

1

You can use two different approaches.

You can create a project that only holds the entity definition (POCO classes) and reference it from all the projects
You can do asyou did in 1. but use models and map them to the entities using AutoMapper or ValueInjecter

The advantage of 2 is that you really decopule the models used in the BL and FE from the entities used by your persisntence layer (DAL). You could also apply this disctintion between the model of the BL and the models that you'll show or edit in the FE (for example implementing view models in MVC).

If you're implementing a simple project, perhaps you'll be satisfied with 1. But if you're implementing something a bit more complicated it can be advisable to use 2.

By the way, instead of implementing a Repository for each entity you'll spare a lot of time if you implemente a base generic repository (i.e Repository<T>) and inherit it for each entity, to implemente only the extar functionality which is not available in the base repository.

Using EF it's easy to implement a generic repository because you can use the DbSet<T> collections.

edited Jun 15 '14 at 16:04

Wiktor Zychla

47,367
6
74
106

answered Jun 15 '14 at 15:34

JotaBe

38,030
8
98
117

A disadvantage of 2. is that you waste the time to constantly map to and from. I would go with 1. – Wiktor Zychla Jun 15 '14 at 16:05
I took the approach the mention in point 1 for a project I did recently at work and for what was required it was more than adequate. But ever since doing it that way it’s been nagging me to find a better way and to fully decouple FE from DAL. – user3742300 Jun 15 '14 at 16:20
Never used AutoMapper or ValueInjector before I’ll have to try then out. Is it true that AutoMapper is quite bloated, this was mentioned in an article I just about it here: http://rogeralsing.com/2013/12/01/why-mapping-dtos-to-entities-using-automapper-and-entityframework-is-horrible/ – user3742300 Jun 15 '14 at 16:20
@user3742300 See my answer here http://stackoverflow.com/a/21361903/1017868 about using a generic repository – MikeSW Jun 16 '14 at 12:34

Using repository model in n-tiered application

1 Answers1