Xml yapılandırması ile Ek açıklama tabanlı yapılandırma [kapalı]

Son zamanlarda üzerinde çalıştığım birkaç büyük projede, birini veya diğerini (XML veya Ek Açıklama) seçmek giderek daha önemli hale geliyor. Projeler büyüdükçe, sürdürülebilirlik için tutarlılık çok önemlidir.

Sorularım şunlar: XML tabanlı yapılandırmanın Ek açıklama tabanlı yapılandırmaya göre avantajları nelerdir ve Ek açıklama tabanlı yapılandırmanın XML tabanlı yapılandırmaya göre avantajları nelerdir?

Ek açıklamalar kendi kullanımlarına sahiptir, ancak XML yapılandırmasını ortadan kaldıracak tek sihirli değnek değildirler. İkisini karıştırmanızı tavsiye ederim!

Örneğin, Spring kullanıyorsanız, uygulamanızın bağımlılık ekleme kısmı için XML kullanmak tamamen sezgiseldir. Bu, kodun bağımlılıklarını onu kullanacak olan koddan uzaklaştırır, bunun aksine, kodda bağımlılıklara ihtiyaç duyan bir tür ek açıklama kullanmak, kodu bu otomatik yapılandırmadan haberdar eder.

Bununla birlikte, işlem yönetimi için XML kullanmak yerine, bir yöntemi bir ek açıklama ile işlemsel olarak işaretlemek mükemmel bir anlam ifade eder, çünkü bu bir programcının muhtemelen bilmek isteyeceği bilgilerdir. Ancak bir arabirimin SubtypeX yerine SubtypeY olarak enjekte edileceği, sınıfa dahil edilmemelidir, çünkü şimdi SubtypeX'i enjekte etmek istiyorsanız, kodunuzu değiştirmeniz gerekir, oysa daha önce bir arabirim sözleşmeniz vardı. XML ile, XML eşlemelerini değiştirmeniz yeterlidir ve bunu yapmak oldukça hızlı ve zahmetsizdir.

JPA ek açıklamalarını kullanmadım, bu yüzden ne kadar iyi olduklarını bilmiyorum, ancak fasulye eşlemelerini XML'de veritabanına bırakmanın da iyi olduğunu, çünkü nesnenin bilginin nereden geldiğini umursamaması gerektiğini savunabilirim. , sadece bilgisiyle ne yapabileceğini önemsemeli. Ama eğer JPA'yı seviyorsanız (bununla ilgili herhangi bir tecrübem yok), elbette, onun için gidin.

Genel olarak: Bir açıklama işlevsellik sağlıyorsa ve kendi başına bir yorum işlevi görüyorsa ve kodu, bu açıklama olmadan normal şekilde çalışması için belirli bir işlemle ilişkilendirmiyorsa, ek açıklamalara gidin. Örneğin, işlemsel olarak işaretlenmiş bir işlem yöntemi, işletim mantığını ortadan kaldırmaz ve aynı zamanda iyi bir kod düzeyinde yorum olarak hizmet eder. Aksi takdirde, bu bilgi muhtemelen en iyi XML olarak ifade edilir, çünkü sonunda kodun çalışma şeklini etkileyecek olsa da, kodun ana işlevini değiştirmez ve dolayısıyla kaynak dosyalara ait değildir.

Burada, dışsallaştırılmış ve satır içi meta-verilere karşı daha geniş bir sorun var. Nesne modeliniz yalnızca bir şekilde kalıcı olacaksa, satır içi meta veriler (yani ek açıklamalar) daha kompakt ve okunabilirdir.

Bununla birlikte, nesne modeliniz, her uygulama modeli farklı şekillerde sürdürmek isteyecek şekilde farklı uygulamalarda yeniden kullanılmışsa, meta verileri (yani XML tanımlayıcıları) dışsallaştırmak daha uygun hale gelir.

Hiçbiri daha iyi değildir ve bu nedenle ek açıklamalar daha moda olmasına rağmen ikisi de desteklenir. Sonuç olarak, JPA gibi yeni yanan çerçeveler, bunlara daha fazla vurgu yapma eğilimindedir. Yerel Hibernate gibi daha olgun API'ler her ikisini de sunar, çünkü ikisinin de yeterli olmadığı bilinmektedir.

Ek açıklamaları her zaman bir sınıfın neler yapabileceğinin veya nasıl yapabileceğinin bir göstergesi olarak düşünürüm. başkalarıyla etkileşime .

Öte yandan, benim için Spring XML yapılandırması tam da bu, yapılandırma

Örneğin, bir proxy'nin ip ve portu hakkındaki bilgiler kesinlikle bir XML dosyasına giriyor, çalışma zamanı konfigürasyonu.

Kullanarak @Autowire,@Element sınıfla ne yapacağını çerçevesini belirtmek için ek açıklamaların iyi kullanılmasıdır.

URL'yi @Webserviceek açıklamaya eklemek kötü bir tarzdır.

Ama bu sadece benim fikrim. Etkileşim ve konfigürasyon arasındaki çizgi her zaman net değildir.

Spring'i birkaç yıldır kullanıyorum ve gereken XML miktarı kesinlikle sıkıcı olmaya başladı. İlkbahar 2.5'teki yeni XML şemaları ve ek açıklama desteği arasında genellikle şunları yapıyorum:

1. @Repository, @Service veya @Component kullanan sınıfları otomatik olarak yüklemek için "bileşen taraması" kullanma. Genellikle her fasulyeye bir isim veriyorum ve ardından @Resource kullanarak onları birbirine bağlarım. Bu tesisatın çok sık değişmediğini ve bu nedenle ek açıklamaların mantıklı olduğunu görüyorum.

2. Tüm AOP'ler için "aop" ad alanını kullanma. Bu gerçekten harika çalışıyor. Hala işlemler için de kullanıyorum çünkü @Transactional'ı her yere koymak bir çeşit engel. Herhangi bir hizmet veya depodaki yöntemler için adlandırılmış nokta yolları oluşturabilir ve tavsiyeleri çok hızlı bir şekilde uygulayabilirsiniz.

3. Hibernate'i yapılandırmak için LocalContainerEntityManagerFactoryBean'i HibernateJpaVendorAdapter ile birlikte kullanıyorum. Bu, Hibernate'in sınıf yolundaki @Entity sınıflarını kolayca otomatik olarak keşfetmesini sağlar. Sonra LCEMFB'ye atıfta bulunan "fabrika fasulyesi" ve "fabrika yöntemi" kullanarak adlandırılmış bir SessionFactory fasulyesi oluşturuyorum.

Yalnızca ek açıklama yaklaşımını kullanmanın önemli bir parçası, "fasulye adı" kavramının az çok ortadan kalkmasıdır (önemsiz hale gelir).

Spring'deki "fasulye adları", uygulama sınıfları üzerinde ek bir soyutlama düzeyi oluşturur. XML ile çekirdekler, çekirdek adlarına göre tanımlanır ve referans alınır. Ek açıklamalarla, sınıfları / arayüzleri tarafından referans alınır. (Fasulye adı mevcut olmasına rağmen bilmenize gerek yoktur)

Gereksiz soyutlamalardan kurtulmanın sistemleri basitleştirdiğine ve üretkenliği artırdığına kuvvetle inanıyorum. İçin büyük projelerin XML kurtularak kazançlar önemli olabilir düşünüyorum.

XML tabanlı bir yaklaşımla görünürlüğün büyük bir kazanç olduğunu düşünüyorum. XML belgelerinde gezinmek için kullanılan çeşitli araçlar (yani, Visual Studio + ReSharper'ın Dosya Yapısı penceresi) göz önüne alındığında, XML'in o kadar da kötü olmadığını görüyorum.

Kesinlikle karma bir yaklaşım benimseyebilirsiniz, ancak bu benim için tehlikeli görünüyor, çünkü potansiyel olarak, bir projedeki yeni geliştiricilerin farklı nesnelerin nerede yapılandırıldığını veya eşlendiğini anlamalarını zorlaştıracaksa.

Bilmiyorum; sonunda XML Hell bana o kadar da kötü görünmüyor.

Yapılandırmak istediğiniz her şeye bağlıdır, çünkü anotasyonlarla yapılandırılamayan bazı seçenekler vardır. Ek açıklamaların yanından bakarsak:

• artı: ek açıklamalar daha az konuşkan
• eksi: ek açıklamalar daha az görünür

Daha önemli olan size kalmış ...

Genel olarak bir yol seçmenizi ve ürünün kapalı bir kısmının her yerinde kullanmanızı tavsiye ederim ...

(bazı istisnalar dışında: örneğin, XML tabanlı konfigürasyonları seçerseniz, @Autowire açıklamasını kullanmanızda bir sorun yoktur. Karıştırır, ancak bu hem okunabilirliğe hem de sürdürülebilirliğe yardımcı olur)

Yeniden düzenleme ve diğer kod değişiklikleri gibi karşılaştırılacak başka yönler de vardır. XML kullanırken, tüm XML içeriğine dikkat etmeniz gerektiğinden yeniden düzenleme yapmak ciddi bir çaba gerektirir. Ancak Ek Açıklamaları kullanırken bu kolaydır.

Benim tercih ettiğim yöntem, ek açıklama içermeyen (veya minimum) Java tabanlı yapılandırmadır. http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java

Yanılıyor olabilirim, ancak Ek Açıklamaların (Java'nın @ Etiketi ve C #'nin [Özniteliğinde] olduğu gibi) bir derleme zamanı seçeneği olduğunu ve XML'in bir çalışma zamanı seçeneği olduğunu düşündüm. Bana göre eşdeğer olmadığını ve farklı artıları ve eksileri olduğunu söylüyor.

Ayrıca bir karışımın en iyi şey olduğunu düşünüyorum, ancak aynı zamanda yapılandırma parametrelerinin türüne de bağlı. Spring'i de kullanan bir Seam projesi üzerinde çalışıyorum ve bunu genellikle farklı geliştirme ve test sunucularına dağıtıyorum. Ben de ayrıldım:

• Sunucuya özel yapılandırma (Sunucudaki kaynaklara giden mutlak yollar gibi): Spring XML dosyası
• Fasulyeleri diğer çekirdeklerin üyeleri olarak enjekte etmek (veya birçok çekirdekte bir Bahar XML tanımlı değerini yeniden kullanmak):

Temel fark, tüm değişen sunucuya özgü yapılandırmalar için kodu yeniden derlemenize gerek olmaması, yalnızca xml dosyasını düzenlemenizdir. Ayrıca, bazı yapılandırma değişikliklerinin ilgili tüm kodu anlamayan ekip üyeleri tarafından yapılabilmesi avantajı da vardır.

DI kapsayıcısı kapsamında, açıklama tabanlı DI, Java açıklamasının kullanımını kötüye kullandığını düşünüyorum. Bunu söyleyerek, projenizde yaygın olarak kullanmanızı önermiyorum. Projeniz gerçekten DI konteynerinin gücüne ihtiyaç duyuyorsa, Spring IoC'yi Xml tabanlı konfigürasyon seçeneği ile kullanmanızı tavsiye ederim.

Yalnızca Birim testi uğruna geliştiriciler, kodlamalarına Bağımlılık Ekleme modelini uygulamalı ve bağımlılıkları aşmak için EasyMock veya JMock gibi alay araçlarından yararlanmalıdır.

DI kapsayıcısını yanlış bağlamında kullanmaktan kaçınmalısınız.

Her zaman belirli bir Java bileşenine (sınıf, yöntem veya alan) bağlanacak olan yapılandırma bilgileri, açıklamalarla temsil edilmek için iyi bir adaydır. Ek açıklamalar özellikle bu durumda, yapılandırma kodun amacının temelini oluşturduğunda iyi çalışır. Ek açıklamalarla ilgili sınırlamalar nedeniyle, her bileşenin yalnızca bir yapılandırmaya sahip olması da en iyisidir. Birden çok konfigürasyonla, özellikle de bir açıklama içeren Java sınıfı dışındaki herhangi bir şeye bağlı olanlar ile uğraşmanız gerekiyorsa, açıklamalar çözdüklerinden daha fazla sorun yaratabilir. Son olarak, ek açıklamalar Java kaynak kodu yeniden derlenmeden değiştirilemez, bu nedenle çalışma zamanında yeniden yapılandırılması gereken hiçbir şey ek açıklamaları kullanamaz.

Lütfen aşağıdaki bağlantılara bakın. Onlar da yararlı olabilir.

1. XML ile ek açıklamalar, avantajları ve dezavantajları
2. http://www.ibm.com/developerworks/library/j-cwt08025/

Bu klasik 'Konfigürasyona karşı Konvansiyon' sorusudur. Kişisel zevk, çoğu durumda cevabı belirler. Bununla birlikte, şahsen ben Konfigürasyonu (yani XML tabanlı) Konvansiyona tercih ediyorum. IMO IDE'leri, insanların genellikle inşa ile ilişkilendirdiği ve XML tabanlı bir yaklaşımı sürdürdüğü bazı XML cehenneminin üstesinden gelmek için yeterince sağlamdır. Sonunda, Yapılandırmanın faydalarının (XML yapılandırma dosyasını oluşturmak, sürdürmek ve dağıtmak için yardımcı programlar oluşturmak gibi) uzun vadede Sözleşmeden daha ağır bastığını görüyorum.

İkisini de kullanıyorum. Çoğunlukla XML, ancak ortak bir sınıftan miras alan ve ortak özelliklere sahip bir grup fasulyeye sahip olduğumda, üst sınıfta bunlar için ek açıklamalar kullanıyorum, bu nedenle her fasulye için aynı özellikleri ayarlamak zorunda kalmam. Biraz kontrol manyağı olduğum için, sadece otomatik kablolama yerine @Resource (name = "referBean") kullanıyorum (ve orijinal referansta Bean ile aynı sınıftan başka bir fasulyeye ihtiyacım olursa kendimi çok fazla zahmetten kurtarıyorum) .

Deneyimlerime göre ek açıklama yapılandırmasının bazı artıları ve eksileri var:

• JPA yapılandırması söz konusu olduğunda, bir kez yapıldığından ve genellikle çok sık değiştirilmediğinden, açıklama yapılandırmasına bağlı kalmayı tercih ederim. Yapılandırmanın daha büyük bir resmini görme olasılığıyla ilgili bir endişe olabilir - bu durumda MSQLWorkbench diyagramlarını kullanıyorum.
• Xml yapılandırması, uygulamanın daha büyük bir resmini elde etmek için çok iyidir, ancak çalışma zamanına kadar bazı hataları bulmak zahmetli olabilir. Bu durumda Spring @Configuration ek açıklaması daha büyük bir resim görmenize ve ayrıca derleme zamanında yapılandırmayı doğrulamanıza izin verdiği için daha iyi bir seçim olarak görünür.
• Spring yapılandırmasına gelince, her iki yaklaşımı birleştirmeyi tercih ediyorum: Hizmetler ve Sorgu arabirimleriyle @Configuration açıklamasını ve dataSource için xml yapılandırmasını ve bağlam: component-scan base-package = "..." gibi yay yapılandırmasını kullanın.
• Ancak xml yapılandırması, akış yapılandırması (Spring Web Flow veya Lexaden Web Flow) söz konusu olduğunda java açıklamalarını biter, çünkü tüm iş sürecinin daha büyük bir resmini görmek son derece önemlidir. Ve ek açıklamalar yaklaşımıyla uygulanması zahmetli geliyor.

Her iki yaklaşımı birleştirmeyi tercih ediyorum - java açıklamaları ve yapılandırma cehennemini en aza indiren minimum xml.

Spring Framework için @Component açıklamasını kullanabilme ve "component-scan" seçeneğini ayarlama fikrini seviyorum, böylece Spring, java çekirdeklerimi bulabilir, böylece tüm çekirdeklerimi XML veya içinde tanımlamama gerek kalmaz. JavaConfig. Örneğin, diğer sınıflara (ideal olarak bir arayüz aracılığıyla) bağlanması gereken durumsuz singleton java çekirdekleri için bu yaklaşım çok iyi çalışıyor. Genel olarak, Bahar fasulyeleri için, fasulyeleri tanımlamak için çoğunlukla Spring XML DSL'den uzaklaştım ve şimdi JavaConfig ve Spring Annotations'ın kullanılmasını tercih ediyorum çünkü yapılandırmanızın bazı derleme zamanı kontrollerini ve bazı yeniden düzenleme desteğini alıyorsunuz. t Spring XML yapılandırmasına geçin. JavaConfig / Annotations'ın XML yapılandırmasını kullanarak mevcut olanı yapamadığını bulduğum bazı nadir durumlarda ikisini karıştırıyorum.

Hibernate ORM için (henüz JPA kullanmadım) XML eşleme dosyalarını tercih ediyorum çünkü etki alanı modeli sınıflarındaki açıklamalar bir dereceye kadar Temiz Mimari'yi ihlal ediyor , son birkaç yıldır benimsediğim katmanlama mimari stili olan . İhlal, Çekirdek Katman'ın Hazırda Bekletme veya JPA kitaplıkları gibi kalıcılıkla ilgili şeylere bağlı olmasını gerektirdiği ve etki alanı modeli POJO'larını biraz daha az kalıcı hale getirdiği için oluşur. Aslında Çekirdek Katman'ın başka herhangi bir altyapıya bağlı olmaması gerekir.

Bununla birlikte, Temiz Mimari sizin "bir fincan çay" değilse, alan modeli sınıflarında ayrı XML eşleme dosyaları yerine Hibernate / JPA ek açıklamalarını kullanmanın kesinlikle avantajları (kolaylık ve bakım kolaylığı gibi) olduğunu görebiliyorum.