Refactoring the Data Access Layer

Question

The Data Access Layer is currently a repetition of 3 function: Create, Get, Set.
On a few Dlo type : Foo, Bar , FooBar.
Where Foo and FooBar have the same implementation and Bar has a more complexe one.

public static bool CreateFooBar(FooBarDlo newFooBar)
{
    bool result = false;
    using (var db = new FooModelDBcontext())
    { 
        db.FooBars.Add(newFooBar);
        result = db.SaveChanges() > 0;
    }
    return result;
}

public static FooBarDlo GetCustomer(int idFooBar)
{
    FooBarDlo result;
    using (var db = new FooModelDBcontext())
    {
        result = db.FooBars.FirstOrDefault(x => x.Id == idFooBar);
    }
    return result;
}

public static bool SetCustomer(FooBarDlo newFooBar)
{
    bool result = false;
    using (var db = new FooModelDBcontext())
    {
        var temp = db.FooBars.SingleOrDefault(x => x.Id == newFooBar.Id);
        db.Entry(temp).CurrentValues.SetValues(newFooBar);
        result = db.SaveChanges() > 0;
    }
    return result;
}

How can those be refactor, while keeping the specificities of the Bar implementation ?

Not exacly sure what you are asking ... create an interface or make an abstract class to derrive from and call base.MyMethod(). For the 'more complex one' call this.VeryComplexThingy()? — nilsK, May 22 '18 at 14:15
@nilsK I was working on a generik implementation and have done a generic Set/Create but that's none of your option. Is it a bad sign ? — xdtTransform, May 22 '18 at 14:17
@nilsK, I thought of an interface but no Static method can be use in it. — xdtTransform, May 22 '18 at 14:22
Generics are good, sure. But we know nothing from your project. So it's pretty hard to guess. Btw, static methods are terrible for unit testing and should be avoided if possible. Yes, sometimes you need static things ;) — nilsK, May 22 '18 at 14:26
Well it's hard to write an question with only One question and a lot of detail. Showing my tentative of implementation of different option would have make this question look weird. Does he wan't me to correct on of the implementation or an other one? make people choose between to broad or to many question. — xdtTransform, May 22 '18 at 14:31

AngryHacker · Accepted Answer · 2018-05-22T14:44:26.657

1

There are several ways to go about it.

You could provide a base class that takes generics as a parameter with all virtual methods (pseudocode)

public abstract class DbLayer<T> {
    public virtual T Get(int Id) {
        // default implementation here
        // but virtual allows overriding   
    }

    public virtual T Create(T obj) {
        // default implementation here
        // but virtual allows overriding               
   }
}

public class FooBarDlo: DbLayer {
   public override FooBarDlo Get(int Id) {
       // override Get handling

   }
}

But if I were you, I'd find a pre-built database layer on CodeProject and go with that.

edited May 22 '18 at 14:44

answered May 22 '18 at 14:25

AngryHacker

59,598
102
325
594

@xdtTransform Sorry, you don't need to have it. I was trying to do a generics constraint - badly. I removed it. – AngryHacker May 22 '18 at 14:44
Ok, and the implementation should be `public class FooBarDlo : DbLayer`, right ? – xdtTransform May 22 '18 at 14:48
Like I said, don't reinvent the wheel. Use an existing implementation. I recommend the Repository Pattern. Read about it [here](https://stackoverflow.com/questions/11985736/repository-pattern-step-by-step-explanation) – AngryHacker May 22 '18 at 14:49
I didn't knew about it ! thx for tyhe reading the first look look very promising this should be in the answer. – xdtTransform May 22 '18 at 14:54

Refactoring the Data Access Layer

1 Answers1