Varlık nesnelerine neden ihtiyacımız var? [kapalı]

Şu anda kabul edilen kurumsal uygulama tasarım paradigmasının esası hakkında gerçekten dürüst ve düşünceli bir tartışma görmem gerekiyor .

Varlık nesnelerinin olması gerektiğine ikna olmadım.

Varlık nesneleri ile, "Kişi", "Hesap", "Sipariş" gibi uygulamalarımız için oluşturduğumuz tipik şeyleri kastediyorum.

Mevcut tasarım felsefem şudur:

• Tüm veritabanı erişimi saklı yordamlarla gerçekleştirilmelidir.
• Verilere ihtiyacınız olduğunda, saklı bir yordamı çağırın ve bir SqlDataReader'ı veya DataTable'daki satırları yineleyin

(Not: Java EE ile kurumsal uygulamalar da oluşturdum, java millet .NET örnekleri için eşdeğer yerine lütfen)

Ben anti-OO değilim. Varlıklar için değil, farklı amaçlar için birçok ders yazıyorum. Yazdığım sınıfların büyük bir bölümünün statik yardımcı sınıflar olduğunu kabul edeceğim.

Oyuncak yapmıyorum. Birden fazla makineye dağıtılan büyük, yüksek hacimli işlem uygulamalarından bahsediyorum. Web uygulamaları, windows hizmetleri, web hizmetleri, b2b etkileşimi, adını siz koyun.

OR Mappers kullandım. Birkaç tane yazdım. Java EE yığınını, CSLA'yı ve diğer birkaç eşdeğeri kullandım. Sadece bunları kullanmakla kalmadım, aynı zamanda bu uygulamaları üretim ortamlarında aktif olarak geliştirdim ve sürdürdüm.

Varlık nesnelerinin yolumuza girdiği savaşta test edilmiş bir sonuca vardım ve onlar olmadan hayatlarımız çok daha kolay olurdu .

Bu basit örneği göz önünde bulundurun: Uygulamanızda düzgün çalışmayan belirli bir sayfa hakkında bir destek çağrısı alırsınız, belki alanlardan biri olması gerektiği gibi kalıcı değildir. Modelimle, sorunu bulmak için atanan geliştirici tam olarak 3 dosya açar . Bir ASPX, bir ASPX.CS ve saklı yordam içeren bir SQL dosyası. Saklı yordam çağrısı için eksik bir parametre olabilecek sorunun çözülmesi birkaç dakika sürebilir. Ancak herhangi bir varlık modelinde, her zaman hata ayıklayıcıyı tetikleyecek, kodla adım atmaya başlayacaksınız ve sonunda Visual Studio'da 15-20 dosya açabilirsiniz. Yığının en altına inene kadar, nereden başladığınızı unuttun. Bir seferde sadece birçok şeyi kafamızda tutabiliriz. Yazılım, gereksiz katmanlar eklemeden inanılmaz derecede karmaşıktır.

Geliştirme karmaşıklığı ve sorun giderme, sorunumun sadece bir tarafı.

Şimdi ölçeklenebilirlik hakkında konuşalım.

Geliştiriciler, veritabanıyla etkileşime giren herhangi bir kodu her yazdıklarında veya değiştirdiklerinde, veritabanı üzerindeki tam etkiyi kapsamlı bir şekilde analiz etmeleri gerektiğini fark ederler mi? Ve sadece geliştirme kopyası değil, yani üretimin bir taklidi, yani nesneniz için şimdi ihtiyacınız olan ek sütunun sadece mevcut sorgu planını geçersiz kıldığını ve 1 saniyede çalışan bir raporun 2 dakika sürdüğünü görebilirsiniz. çünkü seçim listesine tek bir sütun eklediniz mi? Ve şimdi ihtiyacınız olan dizin o kadar büyük ki DBA dosyalarınızın fiziksel düzenini değiştirmek zorunda kalacak?

İnsanların fiziksel veri deposundan soyutlama ile çok uzaklaşmasına izin verirseniz, ölçeklenmesi gereken bir uygulama ile tahribat yaratacaktır.

Ben bir gayret değilim. Linq to Sql, ADO.NET EF, Hibernate, Java EE, vb.'ye doğru güçlü bir itiş olduğu için yanılıyorsam ikna olabilirim ve belki de öyleyim. gerçekten ne olduğunu ve neden düşüncemi değiştirmem gerektiğini bilmek istiyorum.

[Düzenle]

Bu soru aniden tekrar aktif gibi görünüyor, bu yüzden şimdi doğrudan birkaç cevap üzerine yorum yaptığım yeni yorum özelliğine sahibiz. Cevaplar için teşekkürler, bunun sağlıklı bir tartışma olduğunu düşünüyorum.

Muhtemelen kurumsal uygulamalardan bahsettiğimden daha açık olmalıydım. Birisinin masaüstünde veya mobil bir uygulamada çalışan bir oyun hakkında gerçekten yorum yapamam.

Birkaç benzer cevaba yanıt olarak burada en üste koymam gereken bir şey var: diklik ve endişelerin ayrılması genellikle varlık / ORM'ye gitme nedenleri olarak belirtilir. Saklı yordamlar, benim için düşünebileceğim endişelerin ayrılmasının en iyi örneğidir. Saklı yordamlar dışında veritabanına diğer tüm erişimlere izin vermezseniz, saklı yordamların giriş ve çıkışlarını koruduğunuz sürece teorik olarak tüm veri modelinizi yeniden tasarlayabilir ve herhangi bir kodu kıramazsınız. Onlar sözleşme ile programlama mükemmel bir örnektir (sadece "seçin *" önlemek ve sonuç kümelerini belgelemek sürece).

Uzun süredir sektörde olan ve uzun ömürlü uygulamalarla çalışan birine sorun: bir veritabanı yaşarken kaç uygulama ve kullanıcı arayüzü katmanı geldi ve gitti? Veri elde etmek için SQL üreten 4 veya 5 farklı kalıcılık katmanı olduğunda bir veritabanını ayarlamak ve yeniden düzenlemek ne kadar zor? Hiçbir şeyi değiştiremezsiniz! ORM'ler veya SQL üreten herhangi bir kod, veritabanınızı taş olarak kilitler .

Bence uygulamanın "mantığının" ne kadar karmaşık olduğu ve nereye uyguladığınız anlaşılıyor. Tüm mantığınız saklı yordamlar içindeyse ve uygulamanızın yaptığı tek şey bu yordamları çağırmak ve sonuçları göstermekse, varlık nesneleri geliştirmek gerçekten zaman kaybıdır. Ancak, nesnelerin birbirleriyle zengin etkileşime sahip olduğu ve veritabanı sadece bir kalıcılık mekanizması olan bir uygulama için, bu nesnelere sahip olmanın değeri olabilir.

Yani, herkese uyan tek bir cevap olmadığını söyleyebilirim. Geliştiricilerin, bazen çok OO olmaya çalışmanın çözdüğünden daha fazla soruna neden olabileceğinin farkında olması gerekir.

Teori, son derece uyumlu, gevşek bağlı uygulamaların ileriye giden yol olduğunu söylüyor.

Yani sanırım bu yaklaşımı, yani endişeleri birbirinden ayırıyorsunuz.

Aspx.cs dosyam veritabanıyla etkileşimde bulunmalı, bir sproc çağırmalı ve IDataReader'ı anlamalı mı?

Bir ekip ortamında, özellikle uygulamanın aspx kısmı ile ilgilenen daha az teknik kişiye sahip olduğunuzda, bu insanların bu şeylere "dokunabilmesi" gerekmiyor.

Etki alanımı veritabanımdan ayırmak beni veritabanındaki yapısal değişikliklerden koruyor, kesinlikle iyi bir şey mi? Tabii veritabanı etkinliği kesinlikle önemlidir, bu yüzden bu konuda en mükemmel olan birisinin, bir yerde, sistemin geri kalanı üzerinde olabildiğince az etkisi olacak şekilde başa çıkmasına izin verin.

Yaklaşımınızı yanlış anlamadığım sürece, veritabanındaki yapısal değişikliklerden biri uygulamanızın yüzeyi ile geniş bir etki alanına sahip olabilir. Endişelerin bu şekilde ayrılmasının benim ve ekibimin bunu en aza indirmesini sağladığını görüyorum. Ayrıca ekibin yeni üyeleri de bu yaklaşımı daha iyi anlamalıdır.

Ayrıca, yaklaşımınız veritabanınızda bulunan başvurunuzun iş mantığını savunuyor gibi görünüyor? Bu benim için yanlış geliyor, SQL veri sorgulamada gerçekten iyi, imho, iş mantığını ifade etmiyor.

İlginç bir düşünce olsa da, kötü eski yapılandırılmamış asp günlerimden beni korku ile dolduran aspx'te SQL'den bir adım uzakta hissetmesine rağmen.

Bunun bir nedeni - etki alanı modelinizi veritabanı modelinizden ayırmak.

Yaptığım şey test odaklı geliştirmeyi kullanmak, böylece önce kullanıcı arayüzümü ve model katmanlarımı yazıyorum ve veri katmanı alay ediliyor, bu yüzden kullanıcı arayüzü ve model etki alanına özgü nesneler etrafında oluşturulmuş, daha sonra bu nesneleri kullandığım teknolojiye eşliyorum Veri Katmanı. Veritabanı yapısının uygulamanızın tasarımını belirlemesine izin vermek kötü bir fikirdir. Mümkünse önce uygulamayı yazın ve veritabanınızın yapısını etkilemesine izin verin, aksi halde değil.

Benim için kayboluyor Uygulamamın verilerin nasıl saklandığı ile ilgilenmesini istemiyorum. Muhtemelen bunu söylediğim için tokatlanacağım ... ama uygulamanız verileriniz değil, veriler uygulamanın bir eseridir. Uygulamamın DataSets, DataTables ve DataRows gibi bir teknoloji değil, Müşteriler, Siparişler ve Öğeler açısından düşünmesini istiyorum ... çünkü bunların ne kadar süreceğini kim bilir.

Her zaman belirli bir miktarda bağlantının olduğunu kabul ediyorum, ancak bu bağlantının aşağıya değil yukarı doğru uzanmasını tercih ediyorum. Bir ağacın uzuvlarını ve yapraklarını gövdesini değiştirebileceğimden daha kolay değiştirebilirim.

Sorguların uygulamaların genel veri erişiminden biraz daha alçak olma eğilimi gösterdiği için sprocs'u raporlama için ayırma eğilimindeyim.

Ayrıca, senaryoyu erkenden uygun bir birim testle, bir sütunun kalıcı olmamanın bir sorun olmayacağı gibi düşünmeye eğilimliyim.

Eric, sen öldün. Gerçekten ölçeklenebilir / bakımı kolay / sağlam bir uygulama için tek gerçek cevap tüm çöpleri dağıtmak ve temellere sadık kalmaktır.

Kariyerimle benzer bir yörünge izledim ve aynı sonuçlara vardım. Tabii ki, biz sapkın olarak kabul edilir ve komik baktı. Ama eşyalarım iyi çalışıyor ve iyi çalışıyor.

Her kod satırına şüphe ile bakılmalıdır.

Önerdiğinize benzer bir örnekle cevap vermek istiyorum.

Şirketimde ürünler için basit bir CRUD bölümü oluşturmak zorunda kaldım, tüm varlıklarımı ve ayrı bir DAL'ı oluşturdum. Daha sonra başka bir geliştirici ilgili tabloyu değiştirmek zorunda kaldı ve hatta birkaç alanı yeniden adlandırdı. Formumu güncellemek için değiştirmek zorunda olduğum tek dosya bu tablo için DAL idi.

(Bence) varlıklar bir projeye ne getiriyor:

Ortogonallik: Bir katmandaki değişiklikler diğer katmanları etkilemeyebilir (veritabanında büyük bir değişiklik yaparsanız, tüm katmanlar arasında dalgalanır, ancak çoğu küçük değişiklik olmaz).

Test edilebilirlik: Veritabanınıza dokunmadan mantığınızı test edebilirsiniz. Bu, testlerinizdeki performansı artırır (daha sık çalıştırmanızı sağlar).

Endişelerin ayrılması: Büyük bir üründe veritabanını bir DBA'ya atayabilir ve o cehennemi optimize edebilir. Modeli, tasarımı için gerekli bilgiye sahip bir iş uzmanına atayın. Web formları vb. Konusunda daha deneyimli geliştiricilere bireysel formlar atayın.

Son olarak, kullandığınız bu olduğundan çoğu ORM eşleyicisinin saklı yordamları desteklediğini eklemek istiyorum.

Şerefe.

Sanırım bu konuda "çiğneyebileceğinizden daha fazla ısırıyor olabilirsiniz". Ted Neward, " Bilgisayar Bilimi Vietnamı" olarak adlandırdığı zaman küstah değildi .

Size kesinlikle garanti edebileceğim bir şey, sayısız diğer blog, forum, podcast vb.'de sıklıkla kanıtlandığı gibi, kimsenin konuya bakış açısını değiştirmeyeceğidir.

Tartışmalı bir konu hakkında açık bir tartışma ve tartışma yapmak kesinlikle sorun değil, sadece bu bir çok kez yapıldı ki, her iki "taraf" da aynı fikirde olmayı kabul etti ve sadece yazılım yazmayı kabul etti.

Her iki tarafta daha fazla okuma yapmak istiyorsanız, Ted'in blogu, Ayende Rahein, Jimmy Nilson, Scott Bellware, Alt.Net, Stephen Forte, Eric Evans vb.

@ Dan, üzgünüm, aradığım şey bu değil. Teoriyi biliyorum. "Çok kötü bir fikir" ifadeniz gerçek bir örnekle desteklenmiyor. Yazılımı daha az zamanda, daha az insanla, daha az hatayla geliştirmeye çalışıyoruz ve kolayca değişiklik yapabilmeyi istiyoruz. Deneyimime göre, çok katmanlı modeliniz yukarıdaki tüm kategorilerde negatiftir. Özellikle veri modelini yaptığınız son şey yapma konusunda. Fiziksel veri modeli 1. günden itibaren önemli bir husus olmalıdır.

Sorunuzu gerçekten ilginç buldum.
Genellikle bir uygulamanın iş mantığını kapsüllemek için objelerin nesnelerine ihtiyacım var. Bu mantığı veri katmanına itmek gerçekten karmaşık ve yetersiz olacaktır.
Bu varlıkların nesnelerinden kaçınmak için ne yapardınız? Aklınızda ne gibi bir çözüm var?

Varlık Nesneleri uygulama katmanında önbelleğe almayı kolaylaştırabilir. Bir veri okuyucuyu önbelleğe almada iyi şanslar.

Varlıkların gerçekte ne olduğu hakkında da konuşmalıyız. Bu tartışmayı okuduğumda, buradaki insanların çoğunun Anemik Alan Modeli anlamında varlıklara baktığı izlenimini edindim . Birçok insan Anemik Alan Modelini bir anti-patlayıcı olarak görüyor!

Zengin alan modellerinde değer vardır. Yani ne Domain Driven Design tüm ilgili. Şahsen OO'nun karmaşıklığı fethetmenin bir yolu olduğuna inanıyorum. Bu, yalnızca teknik karmaşıklık değil (veri erişimi, kullanıcı arabirimi bağlaması, güvenlik ... gibi), aynı zamanda iş alanındaki karmaşıklık anlamına da gelir !

Analiz etmek, modellemek, tasarlamak ve uygulamak için OO tekniklerini uygulayabilirsekİş problemlerimizi için , bu önemsiz olmayan uygulamaların sürdürülebilirliği ve genişletilebilirliği için muazzam bir avantajdır!

Varlıklarınız ve tablolarınız arasında farklılıklar var. Varlıklar modelinizi, tablolar sadece modelinizin veri yönünü temsil etmelidir!

Veriler daha uzun uygulamalardan daha yaşıyor, ama dikkate doğrudur bu alıntıyı gelen David Laribee : Modeller sonsuza vardır ... veri mutlu bir yan etkidir.

Bu konuyla ilgili bazı bağlantılar:

• Setters ve Getters neden kötüdür?

• Saf OO'nun Dönüşü

• POJO ve NOJO

• Süper modelleri bölüm 2

• TDD, Alaycılar ve Tasarım

Gerçekten ilginç bir soru. Dürüst olmak gerekirse, varlıkların neden iyi olduğunu kanıtlayamıyorum. Ama neden onları sevdiğimi düşünüyorum. Gibi kod

void exportOrder(Order order, String fileName){...};

DB'den, web isteğinden, birim testinden vb. siparişin nereden geldiğiyle ilgili değildir. DataRow'u almak ve hangi sütunlara sahip olmasını beklediklerini ve hangi türleri belgelemek yerine, bu yöntemi tam olarak neye ihtiyaç duyduğunu daha açık bir şekilde beyan eder. olmak. Saklı yordam olarak bir şekilde uygularsanız da aynı şey geçerlidir - DB'de bulunması gerekmediği halde yine de kayıt kimliğini zorlamanız gerekir.

Bu yöntemin uygulanması, DB'de tam olarak nasıl sunulduğuna göre değil, Sipariş soyutlamasına dayalı olarak yapılacaktır. Gerçekleştirdiğim bu tür işlemlerin çoğu, bu verilerin nasıl saklandığına bağlı değildir. Bazı operasyonların performans ve ölçeklenebilirlik amaçları için DB yapısı ile eşleşmeyi gerektirdiğini anlıyorum, sadece tecrübelerime göre çok fazla yok. Deneyimlerime göre, Kişinin .getFirstName () dönen String'i ve .getAddress () Adresini döndürdüğünü ve adresin .getZipCode () vb. .

Ek sütun sonları rapor performansında olduğu gibi, açıkladığınız gibi sorunlarla uğraşmanız gerekiyorsa, görevleriniz için DB kritik bir parçadır ve gerçekten de olabildiğince yakın olmalısınız. Varlıklar bazı uygun soyutlamaları sunarken, bazı önemli ayrıntıları da gizleyebilirler.

Ölçeklenebilirlik burada ilginç bir noktadır - muazzam ölçeklenebilirlik gerektiren web sitelerinin çoğu (facebook, livejournal, flickr gibi) DB mümkün olduğu kadar nadir kullanıldığında ve ölçeklenebilirlik sorunları özellikle RAM kullanımı ile önbelleğe alındığında çözülür. http://highscalability.com/ adresinde bazı ilginç makaleler var.

Soyutlama ve gevşek bağlamanın yanı sıra varlık nesneleri için başka iyi nedenler de vardır. En sevdiğim şeylerden biri, bir DataReader veya DataTable ile elde edemeyeceğiniz güçlü yazımdır. Başka bir neden de, uygun varlık sınıflarının, koda bakan herkesin kullanılan alan adlarına sahip bir dizi dizeden çok anlayabileceği alana özgü terimler için birinci sınıf yapılar kullanarak kodu daha kolay hale getirebilmesidir. bir DataRow dizini oluşturmak için. Saklı yordamlar bir ORM kullanımı ile gerçekten dikeydir, çünkü birçok harita çerçevesi size sprocs ile eşleme olanağı sağlar.

Sprocs + datareaders'ı iyi bir ORM yerine koyamazdım. Saklı yordamlarda, hala çağıran koddan farklı bir tür sistemi kullanan yordamın tip imzasıyla kısıtlanmış ve buna sıkı sıkıya bağlısınız. Saklı yordamlar, ek seçenekler ve şema değişikliklerini değiştirmek için değiştirilebilir. Şemanın değişebileceği durumda saklı yordamlara bir alternatif görünümler kullanmaktır - nesneleri görünümlerle eşleştirebilir ve daha sonra değiştirdiğinizde görünümleri alttaki tablolarla yeniden eşleştirebilirsiniz.

Deneyiminiz çoğunlukla Java EE ve CSLA'dan oluşuyorsa ORM'lerden kaçınmanızı anlayabilirim. Çok hafif bir çerçeve olan ve öncelikle veritabanı tabloları ile bire bir eşleme olan, ancak genellikle tam gelişmiş iş nesneleri olmaları için küçük bir uzantıya ihtiyaç duyan LINQ to SQL'e bakmak isteyebilirsiniz. LINQ to SQL, giriş ve çıkış nesnelerini saklı yordamların parametrelerine ve sonuçlarına eşleyebilir.

ADO.NET Entity çerçevesinin avantajı, veritabanı tablolarınızın birbirinden miras varlık varlıkları veya tek bir varlıkta toplanan birden çok tablodan sütunlar olarak görüntülenebilmesi avantajına sahiptir. Şemayı değiştirmeniz gerekirse, gerçek uygulama kodunu değiştirmeden kavramsal modelden depolama şemasına eşlemeyi değiştirebilirsiniz. Ve yine, saklı prosedürler burada kullanılabilir.

İşletmelerdeki daha fazla BT projesinin, kodun sürdürülememesi veya bir uygulamanın ölçeklenebilirlik sorunlarından ziyade (örneğin, sproc-yazma ve uygulama yazma arasındaki bağlam geçişinden kaynaklanabilecek) zayıf geliştirici verimliliği nedeniyle başarısız olduğunu düşünüyorum.

Ayrıca Dan'in cevabına , her iki modeli de ayırmanın uygulamanızın farklı veritabanı sunucularında veya hatta veritabanı modellerinde çalışmasını sağlayabileceğini eklemek istiyorum .

Birden fazla web sunucusunu yük dengeleme yoluyla uygulamanızı ölçeklendirmeniz gerekirse ne olur? Tüm uygulamayı tüm web sunucularına yükleyebilirsiniz, ancak daha iyi bir çözüm, web sunucularının bir uygulama sunucusuyla konuşmasını sağlamaktır.

Ancak herhangi bir varlık nesnesi yoksa, konuşacak çok şeyleri olmayacaktır.

Basit, içsel, kısa ömürlü bir uygulama ise monolit yazmamanız gerektiğini söylemiyorum. Ancak orta derecede karmaşıklaşır ya da önemli bir süre sürmesi gerektiğinde, gerçekten iyi bir tasarım düşünmeniz gerekir.

Bu, bakım konusunda zaman kazandırır.

Uygulama mantığını sunum mantığı ve veri erişiminden bölerek ve DTO'ları aralarında geçirerek bunları birbirinden ayırırsınız. Bağımsız olarak değişmelerine izin vermek.

Sen bulabilir bu comp.object ilginç üzerine yazı.

Katılıyorum ya da katılmıyorum iddia etmiyorum ama ilginç ve (bence) bu konuyla ilgili.

Bir soru: Tüm iş mantığınız veritabanında sıkışmışsa, bağlantısı kesilmiş uygulamaları nasıl ele alırsınız?

İlgilendiğim Kurumsal uygulama türünde, birden fazla site ile uğraşmak zorundayız, bazıları bağlantısız durumda çalışabilmelidir.
İş mantığınız çeşitli uygulama türlerine dahil edilmesi basit bir Alan adı katmanında kapsüllenmişse (örneğin,dll , iş kurallarının farkında olan ve gerektiğinde bunları yerel olarak uygulayabilen uygulamalar oluşturabilirim.

Domain katmanını veritabanında saklı yordamlarda tutmak için, veritabanına kalıcı bir görüş alanı gerektiren tek bir uygulama türüne bağlı kalmanız gerekir.

Belirli bir ortam sınıfı için uygundur, ancak kesinlikle tüm Kurumsal uygulama yelpazesini kapsamaz .

@jdecuyper, sık sık kendi başıma tekrarladığım bir maksim "iş mantığınız veritabanınızda yoksa, bu sadece bir tavsiye" dir. Sanırım Paul Nielson bunu kitaplarından birinde söyledi. Uygulama katmanları ve kullanıcı arayüzü gelir ve gider, ancak veriler genellikle çok uzun süre yaşar.

Varlık nesnelerini nasıl önleyebilirim? Saklı yordamlar çoğunlukla. Ayrıca, iş mantığının bir uygulamadaki tüm katmanlara ulaşma eğiliminde olup olmadığına bakılmaksızın serbestçe itiraf ediyorum. Belli bir miktarda bağlantı doğal ve kaçınılmazdır.

Aynı şeyi son zamanlarda çok fazla düşünüyorum; Bir süredir CSLA'nın yoğun bir kullanıcısıydım ve "tüm iş mantığınızın (veya en azından makul olarak mümkün olduğu kadarıyla) ticari kuruluşlarda kapsüllendiğini" söylemenin saflığını seviyorum.

İş varlık modelinin, veritabanının tasarımının, birçok iş yazılımında olduğu gibi verilerle çalışma şeklinizden farklı olduğu durumlarda çok fazla değer sağladığını gördüm.

Örneğin, bir "müşteri" fikri, bir Müşteri tablosunda, müşterinin verdiği tüm siparişlerin yanı sıra müşterinin tüm çalışanları ve iletişim bilgileri ve bir müşteri ve çocukları arama tablolarından belirlenebilir. Müşteri açısından tek bir varlık olarak çalışabilmek gerçekten güzel bir gelişmedir, çünkü bir iş perspektifinden Müşteri kavramı tüm bunları içerir ve ilişkiler veritabanında uygulanabilir veya olmayabilir.

"İş kuralınız veritabanınızda değilse, sadece bir öneri değilse" teklifini takdir etsem de, iş kurallarını uygulamak için veritabanını tasarlamamanız gerektiğine inanıyorum, verimli, hızlı ve normalleştirilmiş olarak tasarlamanız gerekir. .

Bununla birlikte, diğerlerinin yukarıda belirttiği gibi, "mükemmel tasarım" yoktur, araç işe uymak zorundadır. Ancak iş varlıklarını kullanmak, bakım ve üretkenliğe gerçekten yardımcı olabilir, çünkü iş mantığını nerede değiştireceğinizi biliyorsunuz ve nesneler gerçek dünya konseptlerini sezgisel bir şekilde modelleyebilir.

Eric

Kimse sizi dilediğiniz çerçeveyi / yaklaşımı seçmekten alıkoymaz. Eğer "veri güdümlü / depolanmış prosedür destekli" yol gidecek, o zaman elbette, bunun için gidin! Özellikle de gerçekten, uygulamalarınızı spesifikasyonlarda ve zamanında teslim etmenize gerçekten yardımcı olur.

Uyarı (sorunuzun tersi), TÜM iş kurallarınızın saklı yordamlarda olması gerekir ve uygulamanız ince bir istemciden başka bir şey değildir.

Bununla birlikte, başvurunuzu OOP'de yaparsanız aynı kurallar geçerlidir: tutarlı olun. Takip Oop en ilkeleri ve varlık oluşturmayı içeren alan adı modellerini temsil etmek nesneleri.

Buradaki tek gerçek kural tutarlılık kelimesidir . Kimse seni DB merkezli olmaya engellemiyor. Kimse sizi eski okul yapılı (işlevsel / prosedürel) programlar yapmaktan alıkoymuyor. Cehennem, hiç kimse kimsenin COBOL tarzı kod yapmasını engellemiyor. AMA herhangi bir başarı elde etmek istiyorsa, bir uygulama bu yolda bir kez çok, çok tutarlı olması gerekir.

"Kurumsal Uygulamalar" olarak düşündüğünüzden gerçekten emin değilim. Ancak, RDBMS'nin taş haline getirileceği ve sistemin dahili veya harici diğer sistemlerle birlikte çalışabilir olması gerekmediği bir Dahili Uygulama olarak tanımladığınız izlenimini ediniyorum.

Ancak, yalnızca temel CRUD işlemleri için her tablo için 4 Saklı Yordam'a eşit olan 100 tabloya sahip bir veritabanınız varsa, korunması gereken ve güçlü bir şekilde yazılması gereken, bu nedenle yazım hatalarına açık olan ve Birim Test Edilebilen 400 saklı yordam . Açık Kaynak Evangelisti olan ve RDBMS'yi SQL Server'dan MySql'ye değiştirmek isteyen yeni bir CTO aldığınızda ne olur?

Kurumsal Uygulamaların veya Ürünlerin SOA kullanıp kullanmadığını ve Web Hizmetlerini göstermek için bazı gereksinimleri olup olmadığını, en azından birlikte olduğum ve dahil olduğum yazılımı bugün birçok yazılım. Yaklaşımınızı kullanarak bir Seri Veri Tablosunu veya DataRow'ları ortaya çıkarabilirsiniz. İstemcinin .NET ve dahili bir ağda olması garanti ediliyorsa, bu kabul edilebilir. Ancak İstemci bilinmediğinde, sezgisel bir API tasarlamaya çalışmalısınız ve çoğu durumda Tam Veritabanı şemasını açığa çıkarmak istemezsiniz. Bir Java geliştiricisine DataTable'ın ne olduğunu ve nasıl kullanılacağını açıklamak istemem. Bant genişliği ve yük boyutu ve serileştirilmiş DataTable'lar da dikkate alınmaktadır, DataSets çok ağırdır.

Yazılım tasarımı ile gümüş bir kurşun yoktur ve gerçekten önceliklerin nerede olduğuna bağlıdır, benim için Birim Test Edilebilir kodunda ve kolayca tüketilebilecek gevşek bağlı bileşenler herhangi bir müşteri olabilir.

sadece 2 sentim

OO ve RDB arasındaki mesafe sorununa başka bir açı daha sunmak istiyorum: tarih.

Herhangi bir yazılımın bir dereceye kadar gerçekliğin soyutlaması olan bir gerçeklik modeli vardır. Hiçbir bilgisayar programı gerçekliğin tüm karmaşıklıklarını yakalayamaz ve programlar sadece bir takım problemleri gerçeklikten çözmek için yazılır. Bu nedenle herhangi bir yazılım modeli gerçekliğin azalmasıdır. Bazen yazılım modeli gerçeği kendisini azaltmaya zorlar. Araba kiralama şirketinin mavi ve alaşımları olduğu sürece sizin için herhangi bir araba ayırmasını istediğinizde olduğu gibi, isteğiniz bilgisayara uymadığı için operatör uymuyor.

RDB, muhasebe adı verilen tablolara bilgi koymak için çok eski bir geleneğe sahiptir. Muhasebe kağıt üzerinde, daha sonra kartlarda, daha sonra bilgisayarlarda yapıldı. Ancak muhasebe zaten gerçekliğin azalmasıdır. Muhasebe, insanları kabul edilen gerçeklik haline geldiği sürece sistemini takip etmeye zorladı. Bu nedenle muhasebe için bilgisayar yazılımı yapmak nispeten kolaydır, muhasebe bilgisayar gelmeden çok önce bilgi modeline sahiptir.

İyi muhasebe sistemlerinin önemi ve herhangi bir işletme yöneticisinden aldığınız kabul, bu sistemler çok gelişmiş hale gelmiştir. Veritabanı temelleri artık çok sağlam ve kimse hayati verileri bu kadar güvenilir bir şeyde tutmaktan çekinmiyor.

Sanırım insanlar gerçekliğin diğer yönlerini modellemekten (zaten bir model olan) muhasebeden daha zor olduğunu keşfettiğinde OO ortaya çıkmış olmalı. OO çok başarılı bir fikir haline geldi, ancak OO verilerinin kalıcılığı nispeten az gelişmiştir. RDB / Muhasebe kolay kazanç elde etti, ancak OO çok daha büyük bir alandır (temel olarak muhasebe olmayan her şey).

Birçoğumuz OO kullanmak istedik, ancak yine de verilerimizin güvenli bir şekilde depolanmasını istiyoruz. Verilerimizi saygın muhasebe sistemi gibi depolamaktan daha güvenli ne olabilir? Bu cazip bir ihtimal, ama hepimiz aynı tuzaklarla karşılaşıyoruz. Muhasebe geleneği ve pozisyonundan yararlanan RDB endüstrisinin muazzam çabalarına kıyasla, OO kalıcılığını düşünmek için çok az şey sıkıntı çekti.

Prevayler ve db4o bazı öneriler, eminim duymadığım başkaları da var, ama hiçbiri hazırda bekletme gibi basının yarısını alamıyor gibiydi.

Nesnelerinizi eski dosyalarda saklamak, çok kullanıcılı uygulamalar ve özellikle web uygulamaları için ciddiye alınmaz gibi görünüyor.

OO ve RDB arasındaki uçurumu kapatmak için yaptığım günlük mücadelemde OO'yu olabildiğince kullanıyorum ama mirasını minimumda tutmaya çalışıyorum. Sıklıkla SP kullanmıyorum. Ben sadece muhasebe gibi görünen yönleri gelişmiş sorgu şeyler kullanacağım.

Uçurum iyice kapatıldığında mutlu olurum. Bence çözüm "Oracle Nesne Örneği Tabanı" gibi bir şey başlattığında gelecek. Gerçekten yakalamak için, güven verici bir isme sahip olması gerekecek.

Şu anda çok fazla zaman değil, ama başımın tepesinde ...

Varlık modeli, saklı yordam arabiriminin yapabileceklerinin ötesinde bile veritabanına (ve diğer olası sistemlere) tutarlı bir arabirim vermenizi sağlar. Kurumsal çaptaki iş modellerini kullanarak, tüm uygulamaların verileri tutarlı bir şekilde etkilediğinden emin olabilirsiniz ki bu çok önemli bir şeydir. Aksi takdirde kötü verilerle sonuçlanırsınız, ki bu sadece kötülüktür.

Yalnızca bir uygulamanız varsa, uygulamanın veya verilerinizin ne kadar büyük olduğuna bakılmaksızın gerçekten bir "kurumsal" sisteminiz yoktur. Bu durumda, konuştuklarınıza benzer bir yaklaşım kullanabilirsiniz. Gelecekte sistemlerinizi büyütmeye karar verirseniz ihtiyaç duyacağınız işin farkında olun.

Aklınızda bulundurmanız gereken birkaç şey (IMO):

1. Oluşturulan SQL kodu bozuk (takip edilecek istisnalar). Maalesef, birçok insanın çok büyük bir zaman tasarrufu olduğunu düşündüğünü biliyorum, ancak yazabileceğimden daha verimli kod üretebilecek bir sistem bulamadım ve kod sadece düz korkunç. Ayrıca çoğu zaman hiç kullanılmayan bir ton SQL kodu üretirsiniz. Buradaki istisna, belki arama tabloları gibi çok basit kalıplardır. Bir çok insan bununla ilgileniyor.
2. Varlıklar <> Tablolar (hatta zorunlu olarak mantıksal veri modeli varlıkları). Bir veri modeli genellikle, tablo satırlarının birbiriyle nasıl ilişkilendiğine dair kuralları veya bildirimsel UR için çok karmaşık olan benzer kuralları içerebilen veritabanına mümkün olduğunca yakın uygulanması gereken veri kurallarına sahiptir. Bunlar saklı prosedürlerde ele alınmalıdır. Saklı yordamlarınızın tümü basit CRUD proc'ları ise bunu yapamazsınız. Bunun da ötesinde, CRUD modeli genellikle performans sorunları yaratır çünkü ağ üzerinden veritabanına gidiş gelişleri en aza indirmez. Bu genellikle bir kurumsal uygulamadaki en büyük darboğazdır.

Bazen uygulamanız ve veri katmanınız o kadar sıkı bir şekilde birbirine bağlı değildir. Örneğin, bir telefon faturalandırma uygulamanız olabilir. Daha sonra, telefon kullanımını a) size daha iyi reklam vermek b) telefon planınızı optimize etmek için izleyen ayrı bir uygulama oluşturursunuz.

Bu uygulamaların farklı endişeleri ve veri gereksinimleri vardır (veriler aynı veritabanından çıksa bile), farklı tasarımları yönlendirir. Kod tabanınız, veritabanının kodu çalıştırmasına izin verirseniz, mutlak bir karmaşa (her iki uygulamada) ve bir kabus ile sonuçlanabilir.

Veri depolama mantığından ayrılmış etki alanı mantığı bulunan uygulamalar, her türlü veri kaynağı (veritabanı veya başka bir şekilde) veya UI (web veya windows (veya linux vb.)) Uygulamasına uyarlanabilir.

Oldukça veritabanınıza sıkışmış, ki bu kötü değilse sizin mevcut veritabanı sisteminden memnun olan bir şirket ile. Ancak, veritabanları fazla mesaiye dönüştüğü için, şirketinizin kullanmak istediği gerçekten temiz ve yeni olan yeni bir veritabanı sistemi olabilir. Ya bir web hizmetleri veri erişimi yöntemine geçmek isteselerdi (bazen Servis Odaklı mimari gibi). Saklı yordamlarınızı her yere taşımanız gerekebilir.

Ayrıca, etki alanı mantığı, sürekli değişen kullanıcı arayüzlerine sahip büyük karmaşık sistemlerde (özellikle sürekli olarak daha fazla müşteri ararken) önemli olabilecek kullanıcı arayüzünü soyutlar.

Ayrıca, saklı yordamlar sorusuna etki alanı mantığına kesin bir cevap olmadığını kabul ederken. Etki alanı mantık kampındayım (ve zaman içinde kazandıklarını düşünüyorum), çünkü ayrıntılı saklı yordamların sürdürülmesi, ayrıntılı etki alanı mantığından daha zor. Ama bu başka bir tartışma

Sadece belirli bir tür başvuru yazmaya ve belirli bir problemi çözmeye alışkın olduğunuzu düşünüyorum. Buna "önce veritabanı" perspektifinden saldırıyor gibisiniz. Verilerin bir DB'ye kalıcı olduğu, ancak performansın öncelikli olmadığı çok sayıda geliştirici var. Birçok durumda, kalıcılık katmanı üzerinde bir soyutlama yapmak kodu büyük ölçüde basitleştirir ve performans maliyeti bir sorun değildir.

Ne yaparsan yap, OOP değil. Yanlış değil, sadece OOP değil ve çözümlerinizi dışarıdaki her türlü probleme uygulamak mantıklı değil.

İlginç soru. Birkaç düşünce:

1. Tüm iş mantığınızın veritabanınızda olup olmadığını nasıl test edersiniz?
2. Veritabanı yapınızdaki değişiklikler, özellikle uygulamanızdaki birkaç sayfayı etkileyenler, uygulama genelinde değiştirmek için büyük bir güçlük olmaz mı?

İyi soru!

Sevdiğim bir yaklaşım, belirli bir bağlamla ilgili nesnelerin örneklerini yayan bir yineleyici / jeneratör nesnesi oluşturmaktır. Genellikle bu nesne bazı temel veritabanı erişim şeylerini sarar, ancak bunu kullanırken bilmeme gerek yok.

Örneğin,

Bir AnswerIterator nesnesi, AnswerIterator.Answer nesneleri oluşturur. Başlık altında, tüm cevapları almak için bir SQL ifadesi ve ilgili tüm yorumları almak için başka bir SQL ifadesi üzerinde yineleniyor. Ancak yineleyiciyi kullanırken, bu bağlam için minimum özelliklere sahip olan Answer nesnesini kullanıyorum. Biraz iskelet kodu ile bunu yapmak neredeyse önemsiz hale geliyor.

Bunun üzerinde çalışacak büyük bir veri kümem olduğunda iyi çalıştığını gördüm ve doğru yapıldığında, test edilmesi nispeten kolay olan küçük, geçici nesneler veriyor.

Temel olarak Veritabanı Erişimi şeyler üzerinde ince bir kaplama, ama yine de bana gerektiğinde soyutlama esnekliği veriyor.

Uygulamalarımdaki nesneler birebir veritabanıyla ilişkilendiriliyor, ancak sprocs yerine Linq To Sql kullanarak buluyorum, karmaşık sorgular yazmayı çok daha kolay hale getiriyor, özellikle de ertelenmiş yürütmeyi kullanarak bunları oluşturabiliyor. örn. r'den Images.User.Ratings burada r'den vb. Bu, sql içinde birkaç join deyimlerini çalıştırmaya çalışmamı sağlar ve sayfalama için Skip & Take'ye sahip olmak, row_number & 'over' kodunu gömmek yerine kodu basitleştirir.

Varlık nesnelerinde neden durmalısınız? Kurumsal düzeydeki bir uygulamadaki varlık nesneleriyle değeri görmüyorsanız, veri erişiminizi tamamen işlevsel / yordamsal bir dilde yapın ve bir kullanıcı arayüzüne bağlayın. Neden sadece tüm OO "tüylerini" kesmiyorsunuz?