"Kullan" anahtar kelimesini kullanırken DRY prensibi nasıl uygulanır?

Bu yöntemleri göz önünde bulundurun:

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();
    }
}

Blok kullanımı aynıdır ve burada 3 kez tekrar edilmiştir (tabii ki gerçek uygulamada 100'den fazla). usingBlok için DRY (Kendini Tekrar Etme) prensibini uygulamak nasıl mümkün olabilir ? DRY müdürünün ihlali sayılır mı?

Güncelleme: usingBloğun içinde uygulananlardan bahsetmiyorum . Aslında burada kastediyorum using (Entities entities = new Entities()). Bu çizgi 100 kez veya daha fazla tekrarlanır.

Bir fikir onu alan bir işlevle sarmak olacaktır Func.

Böyle bir şey

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

Ardından yukarıdaki kodunuz olur

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());
}

Ben de Entitiesbir tür param yaptım , çünkü bunu yaptığınız birden fazla tip olduğunu farz ediyorum. Değilse, onu kaldırabilir ve dönüş türü için sadece param türünü kullanabilirsiniz.

Dürüst olmak gerekirse, bu tür bir kod okunabilirliğe hiç yardımcı olmuyor. Tecrübelerime göre, daha fazla Jr çalışanı onunla gerçekten zor anlar yaşadı.

Güncelle Göz önünde bulundurabileceğiniz yardımcılara ilişkin ek varyasyonlar

//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.

Bana göre bu, aynı koleksiyona defalarca katılmaktan endişe etmek gibi olurdu: Bu sadece yapmanız gereken bir şey. Daha fazla soyutlama girişimi, kodu daha az okunabilir hale getirir.

DRY ilkesiyle "Bir Kez ve Bir Kez" ilkesini karıştırıyormuşsunuz gibi geliyor. KURU ilkesi şöyledir:

Her bilgi parçasının bir sistem içinde tek, açık ve net bir temsiline sahip olması gerekir.

Bununla birlikte, Bir Kez ve Bir Kez prensibi biraz farklıdır.

[KURU] ilkesi OnceAndOnlyOnce'e benzer, ancak farklı bir amacı vardır. OnceAndOnlyOnce ile, çoğaltılmış kod ve işlevselliği ortadan kaldırmak için yeniden yönlendirici kullanmaya teşvik edilir. DRY ile, sisteminizde kullanılan her bilgi parçasının tekil ve kesin kaynağını tanımlamaya çalışırsınız ve ardından bu kaynağı bu bilginin uygulanabilir örneklerini (kod, dokümantasyon, testler, vb.) Üretmek için kullanırsınız.

DRY prensibi genellikle gerçek mantık bağlamında kullanılır, ifadeleri kullanmak çok fazla değil:

Bir programın yapısını korumak DRY daha zordur ve daha düşük bir değerdir. İş kuralları, if ifadeleri, matematik formülleri ve yalnızca bir yerde görünmesi gereken meta verilerdir. WET sayfalarında - HTML sayfaları, yedekli test verileri, virgüller ve {} sınırlayıcılar - bunların tümü göz ardı edilebilir, bu nedenle bunları KURUTMAK daha az önemlidir.

Kaynak

usingBurada kullanımını göremiyorum :

Peki ya:

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();
}

Daha da iyisi, her seferinde yeni bir nesne oluşturmanız gerekmediğini düşünüyorum.

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();
}

DRY ihlalinde gelince: DRY bu seviyede geçerli değildir. Aslında okunabilirlik dışında hiçbir prensip yoktur. DRY'yi bu seviyede uygulamaya çalışmak gerçekten sadece mimari mikro-optimizasyondur, ki tüm mikro-optimizasyonlar sadece bisiklet dökümüdür ve herhangi bir problemi çözmez, hatta yenilerini ortaya koyma riski de vardır.
Kendi tecrübelerime göre, bu seviyedeki kod yedekliliğini azaltmaya çalışırsanız, gerçekten net ve basit olanı gizleyerek kod kalitesi üzerinde olumsuz bir etki yarattığınızı biliyorum.

Düzenleme:
Tamam. Yani sorun aslında using ifadesi değildir, sorun her zaman yarattığınız nesneye bağımlılıktır. Bir yapıcı enjekte etmenizi öneririm:

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

Sadece bir kod kullanmak değil (bu arada kod bir koddur ve aslında bir try..catch..finally deyimi ile karşılaştırılır). Bu şekilde kodunuzu tekrar gözden geçiririm:

 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));
}

Sonuncusu dışında, burada hiçbir iş mantığı olmadığı için. Benim görüşüme göre, gerçekten kuru değil.

Sonuncusu, kullanım bloğunda herhangi bir DRY'ye sahip değil ama sanırım nerede bir cümle, kullanılmış olan yeri değiştirmeli.

Bu, kod üreteçleri için tipik bir iştir. Kod üretecini yazıp kapatın ve her tür için oluşturmasına izin verin.

Aynı tek kullanımlık nesneyi tekrar tekrar yarattığınız ve yok ettiğiniz için, sınıfınız, yeniden şekillendirilebilir modeli uygulamak için iyi bir adaydır.

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();
    }
}

Bu, yalnızca sınıfınızın bir örneğini oluştururken "kullanmaya" ihtiyaç duymanıza izin verir. Nesnelerin atılmasından sınıfın sorumlu olmasını istemiyorsanız, yöntemlerin bağımlılığı bir argüman olarak kabul etmesini sağlayabilirsiniz:

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();
}

En sevmediğim telafi edilemez sihir!

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());
  }
}

WrapSadece bunu ortaya çıkarmak veya ihtiyacınız olan her türlü sihri özetlemek için var. Bunu her zaman tavsiye edeceğimden emin değilim ama kullanmak mümkün. “Daha iyi” fikri, StructureMap gibi bir DI kap kullanmak ve sadece Varlıklar sınıfını istek bağlamına dahil etmek, kontrol ünitesine enjekte etmek ve kontrol ünitesine gerek duymadan yaşam döngüsüne bakmasını sağlamak olacaktır.