EJB ve POJO

Yaklaşık 4 senedir enterprise java projelerinde görev almaktayım. Son 2 senedir içerisinde bulunduğum projede Spring, Hibernate ve JSF gibi teknolojiler kullanılarak büyük bir proje yapılmakta, daha önceki 2 senemde içerisinde bulunduğum yine büyük bir projede ise Swing ve EJB 2 kullanılmaktaydı. Bu blogda hem EJB hem de lightweight container lar kullanmış bir yazılım geliştirici olarak bu konulardaki gözlemlerimi paylaşacağım.

Mezun olduğum zamanlar (2002) inanılmaz bir EJB fırtınası esiyordu ortalıkta. Hangi arkadaşımla görüşsem J2EE öğrenmem gerektiğini zaten J2EE öğrenmenin yaklaşık olarak EJB öğrenmek olduğundan bahsediyorlardı bana. Ben o sıralar İstanbulda küçük bir firmada VB 6 da buttonlara onClick() falan yazıyorum. Sonuçta yönelimimi java olarak belirleyip askerlikten sonra kendimi büyük bir şirkette büyük bir projenin ortasında buldum. Projenin mimari yapısı genel olarak EJB kullanılan J2EE projelerine benzemekteydi. Yani, session bean -> DAO -> entity bean çağrıları yapılıp sunum için gerekli alanları barındıran getter ve setter ları olan DTO (Data Transfer Object) lar da client server arası gider gelir. Geliştirimde EJB kaynaklı bazı sıkıntılar yaşamadığımız gibi kafamızda bazı soru işaretleri vardı. Örneğin;
· Entity beanleri insert ve update için kullanıp sorgularda pure SQL kullanıyorduk. (daha sonra entity bean iyice çileden çıkarınca insert ve update ler de SQL le yapılır oldu)
· EJB deployment descriptor lar oldukça karmaşıktı ve karıştımı bir daha toparlaması çok zor oluyordu. Bu sebeple entity bean değişikliklerimizi takımdan bir kişi yapardı, bunun deployment ı da epey sürerdi zaten.
· Session beanler de, entity beanler de ilginç interface leri implement ettikleri için kullanmadığımız pek çok metoda sahiptiler. Ekleyeceğimiz her özellik için session bean de ve DAO da yeni bir metod yazıyorduk, iş kurallarıda session bean de metodun içinde tabii. Bu pratik asıl bakım aşamasında sıkıntı doğurmuştu. 5000 satırlık session beanler ve 500 satırlık metodlar bu şekilde doğuyor.
· Öğrendiğimiz Object Oriented konseptlerle javanın Object Oriented bir dil olmasına rağmen hiç karşılaşmadım. Ortada ne bir Domain Model ne de iş mantığını içinde barındıran özel amaçlı sınıflar vardı. Her şey kafanın içinde.
· DB de herhangibir değişikliğin nereyi patlatabileceği hakkında yorum yapmak oldukça zordu. Gözden kaçan SQL ler olabiliyor. Zaten persistent frameworklerin çıkış amaçlarından biri de SQL karmaşasına son vermek değil mi?
Bu saydıklarımın hiç biri bizim yanlışımızdan kaynaklı sorunlar değil. EJB ile geliştirilen projelerin hemen hepsinde benzer sıkıntılar yaşanmış.

Bu sebeple bazı yazılım geliştiriciler acaba J2EE uygulamaları daha basit bir şekilde yazılamaz mı diye kafa yormuş ki ortaya Spring gibi Hibernate gibi lightweight framework ler çıktı. Yazılım dünyası EJB den Spring, Hibernate ikilisine öyle hızlı kaçtı ki sonradan çıkan EJB 3 belki de hakettiği ilgiyi göremedi. EJB 3 ile yazılım geliştirmedim ama okuduğum kadarıyla geliştiricilerin serzenişleri dikkate alınmış ve daha kullanılabilir bişey çıkmış ortaya. Ama bence hala Spring, Hibernate ikilisinin gerisinde.

Önceki projem de Spring i, Hibernate i duyup biraz okudum. Sonra yönelimimi Spring olarak belirleyim şimdiki projeme geldim :).

Spring in ve Hibernate in bence en güzel yanları Domain Modelinize ve POJO larınıza hiç bir şekilde müdahele etmemeleri. Enterprise bir uygulama geliştirirken transaction management ve security gibi servislere ihtiyaç duyarsınız. Daha önce EJB Container tarafından sağlanan bu servisler Spring ile kolayca sağlanabiliyor. Örneğin bir iş servisinin transactional yapılması için belli bir interface i implement etmesi gerekmiyor, Spring ile bunu 2 satır xml yazarak sağlayabiliyorsunuz. Spring ve Hibernate ile POJO tabanlı yazılım geliştirirken iş mantığınız üzerine yoğunlaşıp gerekli diğer servisler için fazlaca vakit harcamanıza gerek kalmıyor. Aşağıdaki tabloda kalsik EJB tarzın ve POJO tabanlı yazılım geliştirmenin kısa bir karşılaştırması yapılmıştır.


Klasik EJB tarzı:
Organizasyon: Prosedural tarz kodlama
Implementation: EJB tabanlı
Database erişimi: JDBC/SQL veya Entity bean
Sunum katmanına dönülen veri: DTO lar
Transaction Management: EJB container managed transactions
Application Assembly: Explicit JNDI lookup

POJO tabanlı:
Organizasyon: Object Oriented dizayn
Implementation: POJO
Database erişimi: Persistence Framework
Sunum katmanına dönülen veri: Business Objects
Transaction Management: Spring Framework
Application Assembly: Dependency Injection

EJB, yazılım geliştiricileri prosedural tarzda kodlamaya zorlarken, POJO tabanlı geliştirim herahangi bir tarza zorlamaz. Eski alışkanlıklar sebebiyle pek çok POJO tabanlı geliştirilen yazılımda maalesef prosedural tarzda geliştirilmeye devam etmiştir. POJO lar birer DTO gibi sadece alanlar ve getter setter larıyla doldurulmuş iş mantığı yine servislere yığılmıştır. Aslında iş mantığının karmaşık olmadığı durumlarda bu tarz geliştirim daha mantıklı olabilir, fakat ortada karışık bir iş mantığı varsa bu mantığı POJO lara koymak ve Object Oriented konseptlerden faydalanmak daha akıllıca olur. Bu konu Martin Fowler ve Chris Richardson gibi ustaların bloglarında da yer almış ve literatüre Anemic Domain Model ve Rich Domain Model olarak geçmiştir.