Uygulama Yaklaşımı Felsefeleri
şelale yaklaşımı
Bir uygulamayı uygulamaya yönelik şelale yaklaşımı, bir tasarımcının son kullanıcı organizasyonunun bir veya daha fazla temsilcisine danışmasını ve uygulamanın tüm özelliklerini yazmasını gerektirir. Tipik olarak, özellikler, son kullanıcının belgeleri kolayca okuyabileceği ve anlayabileceği şekilde yazılmış bir dizi işlevsel belge veya kullanım senaryosunda gelir.
Son kullanıcı bu belgeleri imzalar ve ardından belgeler, uygulamayı tasarlayan teknik tasarım ekibi tarafından toplanır ve sınıf modeli diyagramları, durum diyagramları, etkinlik diyagramları ve veri modelleri gibi çeşitli yapılar oluşturulur. Bu aşamanın amacı, bir geliştiricinin gerekli kodu oluşturmakta sorun yaşamayacak kadar ayrıntılı bir şekilde her şeyi yazmaktır. Tasarımın geliştirme ekibine ve test ekibine resmi bir devri vardır. Teslimattan sonra, geliştirme ekibi kodlamaya başlar ve test ekibi, test senaryoları ve test senaryoları oluşturmak için kullanım senaryolarıyla birlikte teknik tasarımı kullanır.
Geliştirme ekibi kodlamayı bitirdikten sonra kod, test ekibine teslim edilir. Test ekibi, gereksinimler ve detaylı tasarıma göre tasarladığı testleri gerçekleştirir. Herhangi bir sorun geliştirme ekibi tarafından giderilecektir. Test ve düzeltme süreci tamamlandıktan sonra, uygulama kabul testi için son kullanıcıya teslim edilir. Son kullanıcı, uygulamanın başlangıç gereksinimlerine uyup uymadığını görmek için son bir kontrol gerçekleştirir. Onaylanırsa bitmiş ürünü onaylar ve proje tamamlanır. Geliştirme ekibi kodlamayı bitirdikten sonra kod, test ekibine teslim edilir.
Test ekibi, gereksinimler ve detaylı tasarıma göre tasarladığı testleri gerçekleştirir. Herhangi bir sorun geliştirme ekibi tarafından giderilecektir. Test ve düzeltme süreci tamamlandıktan sonra, uygulama kabul testi için son kullanıcıya teslim edilir. Son kullanıcı, uygulamanın başlangıç gereksinimlerine uyup uymadığını görmek için son bir kontrol gerçekleştirir. Onaylanırsa bitmiş ürünü onaylar ve proje tamamlanır. Geliştirme ekibi kodlamayı bitirdikten sonra kod, test ekibine teslim edilir. Test ekibi, gereksinimler ve detaylı tasarıma göre tasarladığı testleri gerçekleştirir.
Herhangi bir sorun geliştirme ekibi tarafından giderilecektir. Test ve düzeltme süreci tamamlandıktan sonra, uygulama kabul testi için son kullanıcıya teslim edilir. Son kullanıcı, uygulamanın başlangıç gereksinimlerine uyup uymadığını görmek için son bir kontrol gerçekleştirir. Onaylanırsa bitmiş ürünü onaylar ve proje tamamlanır.
Son kullanıcı, uygulamanın başlangıç gereksinimlerine uyup uymadığını görmek için son bir kontrol gerçekleştirir. Onaylanırsa bitmiş ürünü onaylar ve proje tamamlanır. Son kullanıcı, uygulamanın başlangıç gereksinimlerine uyup uymadığını görmek için son bir kontrol gerçekleştirir. Onaylanırsa bitmiş ürünü onaylar ve proje tamamlanır.
Şelale yaklaşımı kullanılırken bir projede az ya da çok aşama olabilir, ancak temel özellik, her aşamanın son derece resmi bir başlangıç ve bitişidir ve çok resmi çıktılara sahiptir.
Şelale yaklaşımının avantajı, her aşamadan sorumlu ekibin sorumluluğunun daha fazla olmasıdır. Neyi teslim etmeleri gerektiği, ne zaman teslim etmeleri gerektiği ve kime teslim etmeleri gerektiği açık. Genellikle, geliştirme ekibinin kullanıcıyla etkileşime girmesi gerekmez. Bu, geliştirmeyi farklı bir ülkeye yaptırırken çok yararlı olabilir.
Şelale yaklaşımının en büyük dezavantajı, her şeyin çok resmi bir şekilde organize edildiği bir ortamda, değişikliklere cevap verme esnekliğinin azalmasıdır. Hareket etmenin bile organize edilmesi gerekiyor. Çok az şirket bunu etkili bir şekilde yapıyor gibi görünüyor ve bu da genellikle genel giderlerde önemli bir artışa neden oluyor. Hatta bazı şirketler, bir projenin maliyetlerini yönetmek için gereksinimlerdeki herhangi bir değişikliği ilk uygulama teslimine kadar erteleyerek, son kullanıcının ihtiyaçlarını karşılamayan bir uygulamayı etkili bir şekilde sunar.
çevik geliştirme
Birçok uzun soluklu yazılım geliştirme projesi bütçeyi aştı ve ürünü zamanında teslim edemedi. Çevik yazılım geliştirme felsefesinin öncülü, tipik olarak bir ila dört hafta süren yinelemeler adı verilen kısa zaman dilimlerinde yazılım geliştirerek riski en aza indirmektir. Her yineleme, kendi minyatür yazılım projesi gibidir ve yeni işlevsellik artışını serbest bırakmak için gerekli tüm görevleri içerir: planlama, gereksinim analizi, tasarım, kodlama, test ve belgeleme. Bir yineleme, ürünün piyasaya sürülmesini garantilemek için yeterli işlevsellik eklemeyebilirken, çevik bir yazılım projesi, her yinelemenin sonunda yeni yazılım yayınlayabilmeyi amaçlar. Her yinelemenin sonunda ekip, projenin önceliklerini yeniden değerlendirir.
Çevik yazılım geliştirmenin amacı, faydalı yazılımın hızlı ve sürekli olarak sunulması yoluyla müşteri memnuniyetini sağlamaktır; her zaman müşterinin ihtiyacı olanı inşa etmeyi hedefleyen; gereksinimlerdeki geç değişikliklere karşı çıkmak yerine onları memnuniyetle karşılayın; değişen koşullara düzenli olarak uyum sağlamak; girişimciler ve geliştiriciler arasında, yüz yüze görüşmenin en iyi iletişim şekli olduğu yakın ve günlük işbirliğine sahip olmak.
Çevik yazılım geliştirmenin ana avantajı, her zaman iş ihtiyaçlarına göre teslim etmeyi amaçlayan değişikliklerle başa çıkma esnekliğidir. Dezavantajı, elbette, kapsamı yönetme, planlama ve bütçeleme karmaşıklığında bir artıştır. Diğer bir yaygın risk, (teknik) belgelere sınırlı dikkat gösterilmesidir.
Artımlı Geliştirme
Artımlı yazılım geliştirme, çevik ve şelale geliştirmenin bir karışımıdır. Bir uygulama, her bir artışın son kullanıcıya iletilebilmesi için artımlı olarak tasarlanır, uygulanır ve test edilir. Son artış tamamlanana kadar proje tamamlanmaz. Ara artışları tanımlayarak ve çevik geliştirmenin bazı avantajlarını kullanarak kademeyi kısaltmayı amaçlar. Bir önceki artışta alınan geri bildirime dayalı olarak, bir sonraki artış sağlanırken ayarlamalar yapılabilir. Bir sonraki artış, yeni kodun yanı sıra daha önce sağlanan kodda yapılan değişiklikleri içerebilir.
Avantaj, formalitelerin yerinde kalması, ancak değişiklik yönetiminin daha kolay hale gelmesidir. Bir uygulamayı birden çok kez test etme ve dağıtma maliyeti, onu yalnızca bir kez yapmaktan daha fazla olacaktır.
Program Akış Kontrolü
Program akış kontrolüne bir yaklaşım seçmek oldukça mimari bir görevdir. Amaç, uygulamanızın, işlevsellik ve kod eklemeye başladığınızda her şeyin kendi yerine sahip olduğu bir plan oluşturmaktır. Yüksek kaliteli kodu daha önce gözden geçirdiyseniz veya yazdıysanız, bu prensibi anlamışsınızdır.
Organizatör Kodu
Program akışını tasarlamanın ilk adımı, uygulamanın bir planını veya taslağını oluşturmaya yardımcı olacak bir dizi kural oluşturarak kodu düzenlemektir. Kod mantıksal bir konumda bulunduğundan bakım, hata ayıklama ve hata düzeltme daha kolay olacaktır. Temel çalışmaları tamamladıktan sonra, uygulamanızın mantığını uygulamak için bir yaklaşım seçebilirsiniz.
Tasarım kalıpları, program akış kontrolünün tasarımında önemli bir rol oynamalıdır. Yıllar içinde birçok kod yazıldı ve tekrar eden problemler için birçok çözüm tasarlandı. Bu çözümler tasarım modellerinde ortaya konmuştur. Yaygın bir yazılım tasarım sorununa bir tasarım deseni uygulamak, meslektaşlarınız tarafından kolaylıkla fark edilebilen ve uygulanabilen çözümler oluşturmanıza yardımcı olacaktır. Benzersiz problemler yine de benzersiz çözümler gerektirecektir, ancak bunları çözmede size yol göstermesi için tasarım modellerini kullanabilirsiniz.
Projeyi Oluşturmak
katmanlar
İlk adım, mantıksal katmanları dikkate almaktır. Katmanların katmanlarla aynı olmadığını, genellikle karıştırıldığını ve hatta aynı kabul edildiğini unutmayın.
katmanlara karşı katmanlar
Katmanlar tamamen kodunuzda sınırlar oluşturmakla ilgilidir. En üst katman, aşağıdaki katmanlardaki koda referanslara sahip olabilir, ancak bir katmanın hiçbir zaman yukarıdaki katmandaki koda referansı olamaz. Katmanlar, katmanların birden fazla bilgisayar arasında fiziksel dağılımını ifade eder. Örneğin, üç katmanlı bir uygulamada, kullanıcı arabirimi bir masaüstü bilgisayarda çalışacak şekilde tasarlanmıştır, uygulama mantığı bir uygulama sunucusunda çalışacak şekilde tasarlanmıştır ve veritabanı bir veritabanı sunucusunda çalışır. katman birkaç katmandan oluşabilir.
Şekil 8-1: Temel üç katmanlı organizasyon
Katmanlar, soyutlama düzeylerini ifade eder. Şekil 8-1'de gösterilen katmanlar çoğu uygulama için geçerlidir. Bu seviyeler ayrıca üç ana katman olarak adlandırılır ve çeşitli başka isimlere sahip olabilir. Kural olarak, sunum katmanındaki kod, uygulama mantığı katmanındaki hizmetleri çağırabilir, ancak uygulama mantığı katmanı, sunum katmanındaki yöntemi çağırmamalıdır. Uygulama mantığı katmanı tarafından uygulanan sorumlulukları atlayacağından, sunum katmanı hiçbir zaman veri erişim katmanını doğrudan çağırmamalıdır. Veri erişim katmanı hiçbir zaman uygulama mantığı katmanını çağırmamalıdır.
Katmanlar yalnızca bir soyutlamadır ve muhtemelen katmanları uygulamanın en kolay yolu projenizde klasörler oluşturmak ve uygun klasöre kod eklemektir. Daha yararlı bir yaklaşım, her katmanı ayrı bir projeye yerleştirmek ve böylece ayrı montajlar oluşturmak olacaktır. Uygulama mantığınızı bir kitaplık derlemesine koymanın yararı, mantığı test etmek için Microsoft Visual Studio veya NUnit kullanarak birim testleri oluşturmanıza izin vermesidir. Ayrıca, her katmanın nereye konuşlandırılacağını seçme konusunda esneklik sağlar.
Fiziksel Katmanlar
Bir kurumsal uygulamada, aynı mantık için birden çok istemciye sahip olmayı beklersiniz. Aslında, bir uygulamayı kurumsal uygulama yapan şey, üç katmanda dağıtılacak olmasıdır: istemci, uygulama sunucusu ve veritabanı sunucusu. Şirketinizin satış departmanı tarafından oluşturulan Microsoft Office Access uygulaması, satış departmanı için çok önemli olmakla birlikte kurumsal bir uygulama değildir.
Uygulama mantığı ve veri erişim katmanlarının genellikle uygulama sunucusunda birlikte konuşlandırıldığını unutmayın. Projeyi tasarlamanın bir kısmı, uygulama sunucusuna uzak .NET veya Web hizmetleri kullanılarak erişilip erişilmeyeceğini seçmektir. Hangisini seçerseniz seçin, sunum katmanında uzak hizmetlere kolayca erişmek için bazı kodlar ekleyeceksiniz. Uygulama sunucunuzdaki hizmetlere erişmek için web hizmetleri kullanıyorsanız, Visual Studio .NET işi sizin yerinize yapacak ve otomatik olarak uzak proxy modelinin bir uygulamasını sağlayarak proxy kodunu oluşturacaktır.
Katmanlara Desen Ekleme
Üç temel katman, üst düzey bir genel bakış sağlar. Sağlam bir kurumsal mimari oluşturmak için bazı yapısal modeller ekleyelim. Sonuç, Şekil 8-2'de gösterilmektedir.
Uygulama mantığı katmanına odaklanın. Şekil 8-2, uygulama mantığına erişmenin cephe modelini kullandığını göstermektedir. Cephe, sınıf kitaplığı gibi daha büyük bir kod gövdesine basitleştirilmiş bir arabirim sağlayan bir nesnedir. Bir cephe, bir kitaplığın iç işleyişindeki harici kod bağımlılıklarını azaltabilir çünkü çoğu kod cepheyi kullanır ve böylece sistem geliştirmede daha fazla esneklik sağlar. Bunu yapmak için cephe, ince taneli nesneler koleksiyonuna kaba taneli bir arayüz sağlayacaktır.
karar akışı
Karar akışı olarak da bilinen program akış kontrolü, uygulama mantığı katmanınızdaki hizmetleri nasıl tasarladığınızla veya bir önceki paragrafta gördüğünüz gibi cephenizdeki yöntemleri nasıl tasarladığınızla ilgilidir.
Hizmetlerinizi organize etmek için iki yaklaşım vardır:
- eylem odaklı
- devlet güdümlü
Eylem odaklı yaklaşım
Hizmetleri kullanıcı eylemlerine göre düzenleyerek, her biri sunum katmanından belirli bir isteği işleyen hizmetler sunarak uygulama mantığını uyguluyorsunuz. Bu aynı zamanda işlem komut dosyası modeli olarak da bilinir. Bu yaklaşım popüler çünkü basit ve çok doğal görünüyor. Bu yaklaşımı izleyen yöntemlere örnek olarak BookStoreService.AddNewOrder(Order order) ve BookStoreService.CancelOrder(int orderId) verilebilir.
Eylemi gerçekleştirmek için gereken mantık, yöntem içinde çok sıralı bir şekilde uygulanarak kodu çok okunabilir hale getirir, ancak yeniden kullanımı da zorlaştırır. Tablo modülü deseni gibi ek tasarım desenleri kullanmak yeniden kullanılabilirliği artırmaya yardımcı olabilir.
Devlet güdümlü yaklaşım
Ayrıca uygulamanın karar akışını çok daha devlet odaklı bir şekilde hayata geçirmek mümkün. Uygulama sunucusu tarafından sunulan hizmetler, doğası gereği daha geneldir, örneğin BookStoreService.SaveOrder(Order order). Bu yöntem, siparişin durumunu inceleyecek ve yeni bir sipariş eklenip eklenmeyeceğine veya mevcut bir siparişin iptal edilip edilmeyeceğine karar verecektir.
veri yapısı projeleri
Veri yapılarınızı tasarlarken birkaç seçim yapmanız gerekir. Birinci seçenek veri depolama mekanizması, ikincisi verilerin kullanım amacı ve üçüncüsü sürüm gereksinimleridir. Veri yapısı tasarımlarına bakmanın üç yolu vardır:
- Hizmetler veri sunar; veriler, ilişkisel veritabanının bir yansımasıdır.
- Veriler nesnelerle eşlenmelidir ve hizmetler nesnelere erişim sağlar.
- Servislerin sunduğu veriler şema tabanlı olmalıdır.
Veri akışı yapınız için temel olarak üçünden birini seçmek, tasarım sürecinin erken bir aşamasında yapılmalıdır. Birçok şirketin, tüm projelerde üç seçenekten birini zorunlu kılan bir şirket yönergesi vardır, ancak mümkün olduğunda, eldeki proje için en uygun yaklaşımı seçerek her proje için seçenekleri yeniden değerlendirmeniz gerekir.
Veri Depolama Motoru Seçme
Uygulamanızı tasarlarken şüphesiz bir çeşit veri deposu tasarlamanız gerekecektir. Aşağıdaki veri depolama depoları ve biçimleri mevcuttur:
- Kayıt
- app.config dosyası
- xml dosyaları
- düz metin dosyaları
- Veri tabanı
- mesaj kuyruğu
Her mağazanın kendine özgü özellikleri vardır ve belirli gereksinimlere göre uyarlanabilir.
Veri akışını tasarlama
ADO.NET kullanarak veri akışı
Uygulama mantığı katmanında veri merkezli hizmetler uygulayarak, veri akışınızı ADO.NET kullanarak tasarlayacaksınız. .NET Framework sınıf kitaplığı, yönetilen koddaki verileri işlemek için kapsamlı bir uygulama programlama arabirimi (API) sağlar. ADO.NET olarak anılan API, System.Data ad alanında bulunabilir. Veri taşıyıcılarının ve veri depolarının tamamen ayrılması, ADO.NET'in önemli bir tasarım özelliğidir. DataSet, DataTable ve DataRow gibi sınıflar, verileri depolamak için tasarlanmıştır, ancak verilerin nereden geldiğine dair hiçbir bilgi tutmazlar. Veri kaynağı belirsiz olarak kabul edilirler. SqlConnection, SqlDataAdapter ve SqlCommand gibi ayrı bir sınıf kümesi, bir veri kaynağına bağlanma, veri alma ve DataSet, DataTable ve DataRow'u doldurma işlemlerini gerçekleştirir. Bu sınıflar, System.Data.Sql, System.Data.OleDB, System.Data.Oracle ve benzeri alt ad alanlarında bulunur. Hangi veri kaynağına bağlanmak istediğinize bağlı olarak sınıfları doğru ad alanında kullanabilirsiniz ve kullandığınız ürünün kapsamına bağlı olarak bu sınıfların az ya da çok işlevsellik sunduğunu göreceksiniz.
DataSet veri kaynağına bağlı olmadığı için bir uygulamada veri akışını yönetmek için oldukça başarılı bir şekilde kullanılabilir. Şekil 8-5, bunu yaparken veri akışını göstermektedir.
Bu projeye bir göz atalım ve birisinin kitabevinize giriş yaptığını ve üç kitap sipariş ettiğini düşünelim. Sunum katmanı, alışveriş sepetinin durumunu yönetti. Müşteri sipariş vermeye hazır ve gerekli tüm verileri sağladı. Emir göndermeyi seçer. Web sayfası, tüm verileri, biri sipariş ve diğeri sipariş için olmak üzere iki DataTable içeren bir DataSet'e dönüştürür; sipariş için bir DataRow ekler; ve sipariş satırları için üç DataRow ekler. Web sayfası daha sonra bu verileri kullanıcıya bir kez daha görüntüler, veri kontrollerini DataSet'e bağlar ve emin misiniz diye sorar. Kullanıcı isteği onaylar ve isteği uygulamanın mantıksal katmanına gönderir. Uygulama mantığı katmanı, gerekli tüm alanların bir değeri olup olmadığını görmek için DataSet'i kontrol eder ve kullanıcının 1000'den fazla US$'ye sahip olup olmadığını görmek için bir kontrol gerçekleştirir. Ödenmemiş faturalarda 00. Her şey yolunda giderse DataSet, veritabanına bağlanan ve DataSet bilgisinden insert deyimleri oluşturan veri erişim katmanına geçirilir.
DataSet'i bu şekilde kullanmak, bir uygulama oluşturmanın ve Framework Class Library'nin gücünü ve ASP.NET'in verileri bir DataSet'e karşı GridView gibi çeşitli denetimlere bağlama becerisini kullanmanın hızlı ve etkili bir yoludur. Basit DataSet nesnelerini kullanmak yerine, Typed DataSet nesnelerini kullanabilir ve uygulama mantığı katmanının yanı sıra sunum katmanında da kod uygulayarak kodlama deneyimini geliştirebilirsiniz. Bu yaklaşımın avantajı aynı zamanda yaklaşımın dezavantajıdır. Veri modelindeki küçük değişiklikler, birçok yöntemin mutlaka imzalarını değiştirmek zorunda kalmasına yol açmaz. Yani bakım açısından, bu gerçekten iyi çalışıyor. Sunum katmanının mutlaka bir kullanıcı arayüzü olmadığını hatırlarsanız, bir web servisi de olabilir. Ve DataSet'in tanımını değiştirirseniz, belki de veritabanındaki bir alanı yeniden adlandırdığınız için, web hizmetinin abone olduğu sözleşmeyi değiştirmiş olursunuz. Tahmin edebileceğiniz gibi, bu bazı önemli sorunlara yol açabilir. Bu senaryo, sunum katmanı yalnızca bir kullanıcı arabirimiyse iyi çalışır, ancak harici sistemlere veya bileşenlere yönelik arabirimler için, uygulamanızın iç işleyişini gizlemek ve verileri, veri modelinizin doğrudan bir klonundan başka bir şeye dönüştürmek isteyeceksiniz. Veri Aktarım Nesneleri (DTO'lar) oluşturmak isteyeceksiniz.
Nesne ilişkisel eşlemeyi kullanarak veri akışı
ADO.NET kullanan veri akışı, veri akışını yönetmek için oldukça veri merkezli bir yaklaşımdır. Veri ve mantık ayrıktır. Spektrumun diğer ucu, daha nesne yönelimli bir yaklaşım benimsiyor. Burada, verileri ve davranışı gruplandırmak için sınıflar oluşturulur. Amaç, uygulamanın oluşturulduğu iş alanında bulunan verileri ve davranışı taklit eden sınıfları tanımlamaktır. Sonuç genellikle bir iş nesnesi olarak adlandırılır. Uygulamayı oluşturan iş nesnelerinin koleksiyonuna etki alanı modeli denir. Bazı geliştiriciler, daha karmaşık mantık tasarlamak için zengin bir etki alanı modelinin daha iyi olduğunu iddia ediyor. Böyle bir ifadeyi kanıtlamak veya çürütmek zordur. Sadece bir seçeneğiniz olduğunu ve bunu yapmanın size bağlı olduğunu bilin.
Şekil 8-6, Şekil 8-5'e benzer bir veri akışını göstermektedir, ancak şimdi nesne ilişkisel eşleme katmanını eklediniz ve DataSet nesnelerini farklı veri taşıyıcılarıyla değiştirdiniz.
Şimdi daha önce yaptığınız gibi adım adım aynısını yapın; Birinin kitabevinizle bağlantı kurduğunu ve üç kitap sipariş ettiğini hayal edin. Sunum katmanı, alışveriş sepetinin durumunu yönetti. Müşteri sipariş vermeye hazır ve gerekli tüm verileri sağladı. Emir göndermeyi seçer. Web sayfası, tüm verileri bir DTO'ya dönüştürür, verileri bir sipariş için tutar ve üç sipariş satırı ile gerektiği gibi nesneleri oluşturur. Web sayfası bu verileri kullanıcıya bir kez daha görüntüler, ASP.NET 2.0'da ObjectDataSource kullanarak DTO'ya karşı veri bağlama kontrolleri yapar ve Emin misiniz? Kullanıcı seçimi onaylar ve DTO, uygulamanın mantıksal katmanına gönderilir. Uygulama mantığı katmanı, DTO'yu üç OrderLine nesnesi içerme özelliğine sahip Order tipi bir iş nesnesine dönüştürür. Sipariş yöntemi. Siparişi doğrulamak ve gerekli tüm alanların bir değere sahip olduğunu doğrulamak için Validate() çağrılır ve kullanıcının bekleyen fişlerde R$ 1.000,00'den fazla olup olmadığını belirlemek için bir kontrol yapılır. Bunu yapmak için sipariş, Order.Customer.GetOutstandingBills() öğesini çağırır. Her şey yolundaysa, Order.Save() yöntemi çağrılır. İstek, istek ve istek satırlarının bir DataSet'te bir DataTable'a eşlendiği ve DataSet'in veri tabanına bağlanan ve gelen ekleme ifadeleri oluşturan veri erişim katmanına geçirildiği nesne ilişkisel eşleme katmanından geçer. DataSet'teki bilgiler. Elbette, nesne-ilişki eşlemenin gerçekleşebileceği birçok yol vardır, ancak bunların tümü bir DataSet'e dönüştürmeyi içermez. Bazıları doğrudan insert deyimini oluşturacak, ancak yine de bu deyimi yürütmek için veri erişim katmanını kullanacak.
Gördüğünüz gibi, bazı dönüşümler gerçekleşiyor. DTO'ların kullanılması gereklidir çünkü bir iş nesnesi davranışı uygular ve davranış değişebilir. Bu değişikliklerin sunum katmanı üzerindeki etkisini en aza indirmek için, verileri iş nesnesinden çıkarıp bir veri aktarım nesnesine dönüştürmeniz gerekir. Java'da, veri aktarım nesnesine genellikle değer nesnesi denir.
İş nesneleriyle çalışmanın büyük bir avantajı, kodunuzu düzenlemenize gerçekten yardımcı olmasıdır. Bir parça karmaşık mantığa dönüp bakarsanız, genellikle çok okunabilir çünkü çok az tesisat kodu vardır. Dezavantajı, çoğu veri deposunun hala ilişkisel olması ve iş nesnelerini ilişkisel verilere eşlemenin oldukça karmaşık hale gelebilmesidir.
şema tabanlı hizmetler
Veri akışını yönetme söz konusu olduğunda iki karşıtlık gördünüz. Birçok varyasyon mümkündür. Yaygın olanı, veri depolamak için kullanıcı arayüzünün temel veri taşıyıcısı olarak bir veri kümesinin kullanıldığı, ancak diğer sistemlerden çağrılan web hizmetleri için ayrı şemaların (DTO'lar) kullanıldığı varyanttır. Uygulama katmanı, ilişkisel verileri önceden tanımlanmış bir şemaya dönüştürür. Bunun ana avantajı, hizmete başvuran herhangi bir uygulamanın, bileşenin herhangi bir dahili uygulamasına bağlı olmamasıdır. Bu, sürüm oluşturmada daha fazla esneklik, arayüzlerin geriye dönük uyumluluğu ve hizmetin arayüzünü değiştirmeden bileşenin uygulanmasını değiştirme yeteneği sağlar.
Elbette web uygulamasında iş nesnelerini kullanabilir ve DTO dönüşümünü atlayabilirsiniz, ancak bu genellikle yalnızca uygulama mantığı web uygulamasıyla birlikte uygulandığında işe yarar. Order.Save()'i çağırmak için bir veritabanı bağlantısına ihtiyacınız olacağını unutmayın. Bunun istenip istenmediği size ve muhtemelen güvenlik müdürünüze bağlıdır.