Kendi Veri Erişimi / Veri Eşleme Katmanınızı yazmak “iyi” bir fikir mi?

Şu anda kullanıma hazır nesne-ilişkisel eşleyici kullanma veya kendimizi döndürme arasında seçim yapma şansımız olan bir durumdayız

Veri katmanı ve iş katmanının maalesef bir araya getirildiği eski bir uygulamamız (ASP.NET + SQL Server) var. Sistem, veri erişimi açısından özellikle karmaşık değildir. İlişkili tablolardan oluşan büyük bir gruptan (35-40) veri okur, bellekte manipüle eder ve özet formatında diğer bazı tablolara geri kaydeder. Şimdi bazı yeniden düzenleme fırsatları var ve Veri Erişimimizi ayırmak ve düzgün bir şekilde yapılandırmak için kullanılacak aday teknolojileri inceliyoruz.

Hangi teknolojiye karar verirsek verelim:

• Etki Alanı Modelimizde Kalıcılık Bilgisiz POCO nesneleri var
• Etki alanı model nesnelerimizi, alay konusu bir veri kaynağına karşı Birim Test Etmemize izin veren bir soyutlama katmanına sahip olmak

Açıkçası bu konuda Desenler ve Çerçeveler vb. Açısından çok fazla şey var.

Şahsen EF'i ADO.NET Birimi Test Edilebilir Depo Oluşturucu / POCO Varlık Oluşturucu ile birlikte kullanmak için bastırıyorum . Tüm gereksinimlerimizi karşılar, bir Repo / UnitOfWork Kalıbı içinde kolayca paketlenebilir ve DB Yapımız, modelde günlük değişiklikler yapmayacak şekilde makul ölçüde olgunlaşır (zaten bir refactor geçirmiş).

Ancak gruptaki diğer kişiler kendi DAL'ımızı tamamen sıfırdan tasarlamayı / yuvarlamayı öneriyor. (Özel DataMappers, DataContexts, Repository, Her yerdeki arayüzler, Somut nesneler oluşturmak için Bağımlılık Enjeksiyonu aşıldı, Özel LINQ-Temel Sorgu Çevirisi, Özel Önbellek Uygulamaları, Özel FetchPlan Uygulamaları ...) liste uzayıp gidiyor beni delilik olarak.

Hakkında atılan argümanlardan bazıları "En azından kendi kodumuzu kontrol edeceğiz" ya da "Ah, önceki bir projede L2S / EF kullandım ve baş ağrılarından başka bir şey değildi". (Her ne kadar daha önce Üretimde kullandım ve arasında çok az ve çok yönetilebilir ve çok yönetilebilir herhangi bir sorun buldum)

Öyleyse uber deneyimli geliştiricilerinizden / mimarlarınızdan herhangi biri, bu ürünü tam bir felaket gibi göründüğümden uzaklaştırmamı sağlayacak herhangi bir bilgelik sözüne sahip mi? EF sorunlarından kaçmakla elde edilen herhangi bir faydanın , tekerleği yeniden icat etmeye çalışarak çabucak kaybedileceğini düşünemiyorum .

Mevcut ORM'lere karşı her iki argüman geçersiz:

"En azından kendi kodumuzu kontrol edeceğiz"

Neden kendi dilinizi yazmıyorsunuz? Kendi çerçeveniz mi? Kendi işletim sisteminiz? Ve her şeyin kontrolünde olduğunuzdan emin olmak için, kendi donanımınızı oluşturmak da iyi bir fikirdir.

"Ah önceki projede L2S / EF kullandım ve baş ağrısından başka bir şey değildi"

EF yeterince olgun ve bol insan tarafından başarıyla kullanıldı. Bu, EF'in baş ağrısından başka bir şey olmadığını iddia eden bir kişinin muhtemelen EF'nin nasıl düzgün kullanılacağını öğrenmeye başlaması gerektiği anlamına gelir.

Kendi ORM'inizi yazmak zorunda mısınız?

Bunu tavsiye etmem. Zaten profesyonel düzeyde ORM'ler var, bu da yalnızca aşağıdaki durumlarda kendiniz yazmak zorunda olduğunuz anlamına gelir:

• Mevcut tüm ORM'lerin bir nedenden dolayı uygun olamayacağı kesin bir bağlamınız var
• Mevcut bir tane öğrenmek yerine kendi ORM'nizi oluşturma ve kullanma maliyetinin çok daha düşük olduğundan eminsiniz. Bu, ORM'nizle nasıl çalışacağınızı anlamak için teknik belgelerinizin yüzlerce sayfasını okumak zorunda kalacak başka bir geliştirici ekibi de dahil olmak üzere gelecekteki destek maliyetini içerir.

Tabii ki, hiçbir şey kendi ORM'nizi meraktan çıkarmanızı, bir şeyler öğrenmenizi yasaklamaz. Ama bunu ticari bir projede yapmamalısınız.

Ayrıca bkz . “Tekerleğin yeniden icat edilmesi ve pişman olmaması ” sorusuna verilen cevabımın 2 ila 3'üncü noktaları . Tekerleği yeniden icat etmenin farklı nedenlerinin burada geçerli olmadığını görebilirsiniz.

Tüm normal CRUD öğeleri için Entity Framework'ü kullanın (kodun yüzde 80 ila 95'i) ve optimize edilmesi gereken kalan kodlar için özel veri erişim kodu kullanın . Bu, yeterli kontrole sahip olmadığınızı iddia edenlerin endişelerini tatmin etmelidir.

Bu kodu ilk etapta oluşturmak için gereken en az zamandan / efordan tasarruf edeceğinizden (ve en azından makul olarak) emin olabiliyorsanız ve iyi bir fikirdir. Duruma bağlı olarak, bunu yapmak programınızı da etkileyebilir ve bunu da hesaba katmanız gerekir. Ayrıca denklemin uzun vadeli bakımını da hesaba katmanız gerekir. Kendi ORM'nizi döndürürseniz, sonsuza kadar (veya en azından kullandığınız sürece) korumanız gerekir.

Sonuç olarak , sadece doğru koşullar altında mantıklı olabilir . Bu koşullar genellikle şunları içerir:

1. Üzerinde çalıştığınız proje oldukça büyük, bu nedenle maliyet büyük miktarda kullanım üzerinden itfa ediliyor.
2. Veri kullanımınız, varolan kitaplıkların (ve benzeri) sizin amaçlarınız için oldukça kötü çalıştığı konusunda olağandışıdır.

Açık olanı belirtme riski altında, bu ikisi tersine ilişkilidir - eğer gerçekten devasa bir proje üzerinde çalışıyorsanız, her bir kullanımda küçük bir tasarruf bile gelişmeyi haklı çıkarmak için yeterli olabilir. Tersine, ihtiyaçlarınız gerçekten sıra dışıysa, her kullanımda çok şey kazanırsanız, çalışma oldukça küçük bir projede bile haklı olabilir.

En azından açıklamanıza dayanarak, sizin durumunuz için de geçerli değildir. Belki bir (hatta her ikisi de) iş arkadaşınızın önceki EF kullanımına başvurdu veya belki de sadece önyargılıydı - Sanırım hangisini tahmin edebilmemiz için yeterli bilgi verdiğinizi sanmıyorum (dürüst olmak gerekirse, Sanırım bu size tahmin etmek için neredeyse yeterince şey söylemediğinden).

Bu durumdan ben sorumlu olsaydım, siz ve çalışma arkadaşlarınızın her birine bir tür pozisyon belgesi yazmasını isterdim - her bir yaklaşımda gördüğünüz güçlü ve zayıf yönlerin bir listesi ve her bir iddiayı / iddiayı destekleyecek gerçek kanıtlar /her neyse. Tüm ekip daha sonra her bir makaleyi eleştirir (yani, talep etmelidir). Eleştirilerindeki birincil nokta, her bir noktayı iki ölçekte değerlendirmek olacaktır:

1. noktanın ne kadar doğru göründüğü, gerçekler tarafından iyi desteklenmiş vb. ve
2. noktanın eldeki projeye uygulanma derecesi.

Sonra bir karar vermek için kağıtları ve eleştirileri değerlendirirdim (tamamen dürüst olmakla birlikte, kararı vermek için ne kadar kullandığımı ve bir kararı haklı çıkarmak için ne kadar kullandığımı söylemek zor olabilir Zaten yapmıştım - muhtemelen bunu kabul etmemeliyim biliyorum, ama gerçek şu ki ben de insanım ...)

Düzenle:

Özellikle kötü (veya "eğitimsel" - bu durumda farkı söylemek zor) olsaydım, her birinizin hem mevcut bir ORM / DAL kullanarak hem de gelişmekte olan genel geliştirme çabasının bir tahminini geliştirmeye çalışırdım kendi. Bu sadece bir tahmin olsa da, kendi tahminimce kendi planlarını yuvarlamak için büyük planları olan insanların çoğu, tahminlerini teslim etmeye zahmet etmeyeceklerdi - uzaktan tamamlanmış bir genel çaba tahmini ile (ve gerçekçi), mevcut kodu kullanarak rekabete yaklaşmanın hiçbir yolu olmadığını fark ederlerdi. Aynı zamanda, '

Edit 2: (@ CmdKey'in önerisinde bir tür): Açıkça belirtilmemesine rağmen, bir tahminin dolaylı olarak bir risk değerlendirmesi içereceğini varsayıyorum. Özellikle, bir zaman tahmini normalde PERT tarzı sayılar içermelidir:

1. Her şey yolunda giderse en hızlı şekilde yapılabilecek en iyi durum.
2. "Normal" tahmin - ne kadar süreceğini düşünüyorsunuz.
3. En kötü durum tahmini, her şey ters gittiğinde alabileceği en uzun süre.

Tabii ki, en iyi ve en kötü durum tahminleri normalde doğrudan ilahi müdahale gibi şeyleri içermemeli, ancak bunun hemen hemen dışında olan her şeyi içermelidir.

Genellikle tekerleği yeniden icat etmek asla iyi bir fikir değildir ve bunu yapmak genellikle teknik cehaletin ("Başka bir şey bilmiyorum ve öğrenmek istemiyorum") veya kibirin ("X aptalca, iki hafta içinde kendi aracımı yaz! "); Bazı ortalama geliştiricilerin birkaç hafta içinde birlikte hackleyebileceğinden çok daha iyi şeyler yapabilen olgun araçlar var.

Bununla birlikte, mevcut bir çözümün (ne kadar esnek olursa olsun) bir ton çalışma olmadan güvenilir bir şekilde eski bir uygulamaya sığamayacağınız zamanlar vardır; böyle bir durumda bu "iyi" bir fikir değil, alternatiflerden daha iyi bir fikirdir (yani olduğu gibi bırakmak veya üçüncü taraf katmanını kullanabilmek için yarısını yeniden yazmak), böylece çok az seçeneğiniz vardır.

Hazırda Bekleme'de bulunmayan bazı "kritik" özellikler nedeniyle, kendi Java yazma araçlarını kendi yazmak için reddeden bir projedeydim. Bu milyonlarca dolarlık bir hataydı ve maliyet her geçen gün artıyor. Nesne ilişkileri için hala tam destekleri yoktur. Bu nedenle, çerçeveyi oluşturmak ve sürdürmek için harcanan tüm zamanlara ek olarak, Hibernate kullanarak dakikalar içinde yazılabilecek veya birçok durumda hiç yazılması gerekmeyecek kod yazarak saatler harcıyorlar.

Mevcut çerçeveler onlarca yıllık çabaların ürünüdür. Tek bir takımın birkaç haftada bir yere yaklaşabileceğini hayal etmek saçmadır.

Yazmanız gereken kod, sürdürmeniz gereken koddur. Zaman harcanan zamanı ORM kodu olduğunu sürdürmek geçirdi değil uygulamayı sürdürmek. ORM size bir tür stratejik avantaj sağlamadığı sürece, bu iş için para üretecek bir şey değildir, bu yüzden saf ek yüktür. Şirketiniz genel masrafa veya para kazandıran bir ürünü geliştirmeye para harcamayı tercih eder mi? Bu dahili bir uygulama içinse, bu bir sorun olmayabilir, ancak yine de yazılması, test edilmesi ve belgelenmesi gereken kod miktarını artırıyorsunuz.

Kendi ORM'nizi yaymanın KÖTÜ bir fikir olduğunu söyleyebilirim - bunu yapmak için çok, çok tanrı bir nedeniniz yoksa (btw. Alıntıladığınız şeyler yeterince iyi değil :)

Bir zamanlar başkalarının beni ORM'yi kullanmamaya ikna etmede bir hata yaptım ve size tüm DAL'ı yazmanın bizi gerçekten yavaşlattığını söyleyebilirim ve iş için önemli olan özellikleri uygulamak yerine DAL'de zaman harcıyoruz (çok daha fazla iş var) göründüğünden daha fazla).

Yeni EF oldukça iyi görünüyor, ancak daha fazla kontrol istiyorsanız - mikro ORM / s'ye şöyle bir bakışım olur: Drapper http://code.google.com/p/dapper-dot-net/ veya PetaPOCO http : //www.toptensoftware.com/petapoco/

Ayrıca karıştırabilir ve eşleştirebilirsiniz - malzemelerin büyük kısmı için EF'i ve bazı ince ayarlar için Drapper'ı kullanın.

Her neyse, bu sadece benim 2c;)