Bagaimana menerapkan prinsip KERING saat menggunakan kata kunci 'menggunakan'?

Pertimbangkan metode ini:

public List<Employee> GetAllEmployees()
{
    using (Entities entities = new Entities())
    {
        return entities.Employees.ToList();
    }
}

public List<Job> GetAllJobs()
{
    using (Entities entities = new Entities())
    {
        return entities.Jobs.ToList();
    }
}

public List<Task> GetAllTasksOfTheJob(Job job)
{
    using (Entities entities = new Entities())
    {
        return entities.Tasks.Where(t => t.JobId == job.Id).ToList();
    }
}

Penggunaan blok sama dan telah diulang 3 kali di sini (tentu saja, lebih dari 100 kali dalam aplikasi nyata). Bagaimana mungkin menerapkan prinsip DRY (Don't Repeat Yourself) untuk usingblok? Apakah itu dianggap sebagai pelanggaran prinsipal KERING sama sekali?

Pembaruan: Saya tidak berbicara tentang apa yang telah diterapkan di dalam usingblok. Apa yang sebenarnya saya maksud di sini, adalah using (Entities entities = new Entities()). Baris ini diulang 100 kali atau lebih.

Satu ide adalah untuk membungkusnya dengan fungsi yang membutuhkan Func.

Sesuatu seperti ini

public K UsingT<T,K>(Func<T,K> f) where T:IDisposable,new()
{
    using (T t = new T())
    {
        return f(t);
    }
}

Maka kode Anda di atas menjadi

public List<Employee> GetAllEmployees()
{
    return UsingT<Entities,List<Employee>>(e=>e.Employees.ToList());
}

public List<Job> GetAllJobs()
{
    return UsingT<Entities,List<Job>>(e=>e.Jobs.ToList());
}

public List<Task> GetAllTasksOfTheJob(Job job)
{
    return UsingT<Entities,List<Task>>(e=>e.Tasks.Where(t => t.JobId == job.Id).ToList());
}

Saya membuat Entitiesparam tipe juga, karena saya berasumsi Anda memiliki lebih dari satu tipe yang Anda lakukan dengan ini. Jika tidak, Anda bisa menghapusnya dan cukup menggunakan param jenis untuk jenis kembali.

Sejujurnya meskipun kode semacam ini tidak membantu keterbacaan sama sekali. Dalam pengalaman saya, semakin banyak rekan kerja Jr yang mengalami kesulitan juga.

Perbarui Beberapa variasi tambahan tentang pembantu yang mungkin Anda pertimbangkan

//forget the Entities type param
public T UsingEntities<T>(Func<Entities,T> f)
{
    using (Entities e = new Entities())
    {
        return f(e);
    }
}
//forget the Entities type param, and return an IList
public IList<T> ListFromEntities<T>(Func<Entities,IEnumerable<T>> f)
{
    using (Entities e = new Entities())
    {
        return f(e).ToList();
    }
}
//doing the .ToList() forces the results to enumerate before `e` gets disposed.

Bagi saya ini akan seperti mengkhawatirkan tentang mencari koleksi yang sama beberapa kali: itu hanya sesuatu yang perlu Anda lakukan. Setiap upaya untuk abstrak lebih lanjut akan membuat kode tersebut jauh lebih mudah dibaca.

Sepertinya Anda mengacaukan prinsip "Once and Only Once" dengan prinsip KERING. Prinsip KERING menyatakan:

Setiap pengetahuan harus memiliki representasi tunggal, tidak ambigu, otoritatif dalam suatu sistem.

Namun prinsip Once dan Only Once sedikit berbeda.

Prinsip [KERING] mirip dengan OnceAndOnlyOnce, tetapi dengan tujuan yang berbeda. Dengan OnceAndOnlyOnce, Anda dianjurkan untuk melakukan refactor untuk menghilangkan duplikasi kode dan fungsionalitas. Dengan KERING, Anda mencoba mengidentifikasi sumber tunggal dan pasti dari setiap bagian pengetahuan yang digunakan dalam sistem Anda, dan kemudian menggunakan sumber itu untuk menghasilkan contoh-contoh yang berlaku dari pengetahuan itu (kode, dokumentasi, tes, dll).

Prinsip KERING biasanya digunakan dalam konteks logika aktual, tidak terlalu berlebihan menggunakan pernyataan:

Menjaga struktur program KERING lebih sulit, dan nilainya lebih rendah. Aturan bisnis, pernyataan if, rumus matematika, dan metadata yang seharusnya hanya muncul di satu tempat. Hal-hal WET - halaman HTML, data uji yang berlebihan, koma dan pembatas {} - semuanya mudah untuk diabaikan, jadi KERING mereka kurang penting.

Sumber

Saya gagal melihat penggunaan di usingsini:

Bagaimana tentang:

public List<Employee> GetAllEmployees() {
    return (new Entities()).Employees.ToList();
}
public List<Job> GetAllJobs() {
    return (new Entities()).Jobs.ToList();
}
public List<Task> GetAllTasksOfTheJob(Job job) {
    return (new Entities()).Tasks.Where(t => t.JobId == job.Id).ToList();
}

Atau bahkan lebih baik, karena saya pikir Anda tidak perlu membuat objek baru setiap saat.

private Entities entities = new Entities();//not sure C# allows for that kind of initialization, but you can do it in the constructor if needed

public List<Employee> GetAllEmployees() {
    return entities.Employees.ToList();
}
public List<Job> GetAllJobs() {
    return entities.Jobs.ToList();
}
public List<Task> GetAllTasksOfTheJob(Job job) {
    return entities.Tasks.Where(t => t.JobId == job.Id).ToList();
}

Adapun untuk melanggar KERING: KERING tidak berlaku pada tingkat ini. Sebenarnya tidak ada prinsip yang benar-benar berlaku, kecuali keterbacaan. Mencoba menerapkan KERING pada tingkat itu benar-benar hanya mikro-optimasi arsitektur, yang seperti semua mikro-optimasi hanya sepeda-shedding dan tidak mendapatkan masalah diselesaikan, tetapi bahkan risiko untuk memperkenalkan yang baru.
Dari pengalaman saya sendiri, saya tahu bahwa jika Anda mencoba mengurangi redundansi kode pada level itu, Anda membuat dampak negatif pada kualitas kode, dengan mengaburkan apa yang benar-benar jelas dan sederhana.

Sunting:
Oke. Jadi masalahnya sebenarnya bukan statemen using, masalahnya adalah ketergantungan pada objek yang Anda buat setiap waktu. Saya sarankan menyuntikkan konstruktor:

private delegate Entities query();//this should be injected from the outside (upon construction for example)
public List<Employee> GetAllEmployees() {
    using (var entities = query()) {//AFAIK C# can infer the type here
        return entities.Employees.ToList();
    }
}
//... and so on

Tidak hanya menggunakan kode duplikat (dengan cara itu adalah kode duplikat dan benar-benar membandingkan dengan coba..catch .. pernyataan terakhir) tetapi toList juga. Saya akan memperbaiki kode Anda seperti ini:

 public List<T> GetAll(Func<Entities, IEnumerable<T>> getter) {
    using (Entities entities = new Entities())
    {
        return getter().ToList();
    }
 }

public List<Employee> GetAllEmployees()
{
    return GetAll(e => e.Employees);
}

public List<Job> GetAllJobs()
{
    return GetAll(e => e.Jobs);
}

public List<Task> GetAllTasksOfTheJob(Job job)
{
    return GetAll(e => e.Tasks.Where(t => t.JobId == job.Id));
}

Karena tidak ada logika bisnis apa pun di sini kecuali yang terakhir. Ini tidak benar-benar KERING, menurut saya.

Yang terakhir tidak memiliki KERING di blok menggunakan tapi saya kira klausa di mana harus berubah di mana pun itu digunakan.

Ini adalah pekerjaan khas untuk pembuat kode. Tulis dan tutup pembuat kode dan biarkan menghasilkan untuk setiap jenis.

Karena Anda membuat dan menghancurkan objek sekali pakai yang sama berulang-ulang, kelas Anda sendiri merupakan kandidat yang baik untuk menerapkan pola IDisposable.

class ThisClass : IDisposable
{
    protected virtual Entities Context { get; set; }

    protected virtual void Dispose( bool disposing )
    {
        if ( disposing && Context != null )
            Context.Dispose();
    }

    public void Dispose()
    {
        Dispose( true );
    }

    public ThisClass()
    {
        Context = new Entities();
    }

    public List<Employee> GetAllEmployees()
    {
        return Context.Employees.ToList();
    }

    public List<Job> GetAllJobs()
    {
        return Context.Jobs.ToList();
    }

    public List<Task> GetAllTasksOfTheJob(Job job)
    {
        return Context.Tasks.Where(t => t.JobId == job.Id).ToList();
    }
}

Ini membuat Anda hanya perlu "menggunakan" saat membuat instance kelas Anda. Jika Anda tidak ingin kelas bertanggung jawab untuk membuang objek, maka Anda bisa membuat metode menerima ketergantungan sebagai argumen:

public static List<Employee> GetAllEmployees( Entities entities )
{
    return entities.Employees.ToList();
}

public static List<Job> GetAllJobs( Entities entities )
{
    return entities.Jobs.ToList();
}

public static List<Task> GetAllTasksOfTheJob( Entities entities, Job job )
{
    return entities.Tasks.Where(t => t.JobId == job.Id).ToList();
}

Sepotong sihir favoritku yang tak bisa dipercaya!

public class Blah
{
  IEnumerable<T> Wrap(Func<Entities, IEnumerable<T>> act)
  {
    using(var entities = new Entities()) { return act(entities); }
  }

  public List<Employee> GetAllEmployees()
  {
    return Wrap(e => e.Employees.ToList());
  }

  public List<Job> GetAllJobs()
  {
    return Wrap(e => e.Jobs.ToList());
  }

  public List<Task> GetAllTasksOfTheJob(Job job)
  {
    return Wrap(e => e.Tasks.Where(x ....).ToList());
  }
}

Wrapada hanya untuk abstrak itu atau sihir apa pun yang Anda butuhkan. Saya tidak yakin saya akan merekomendasikan ini sepanjang waktu tetapi mungkin untuk digunakan. Gagasan "yang lebih baik" adalah dengan menggunakan wadah DI, seperti StructureMap, dan hanya lingkup kelas Entitas ke konteks permintaan, menyuntikkannya ke dalam pengontrol, dan kemudian membiarkannya mengurus siklus hidup tanpa perlu pengontrol Anda.