MVC, MVP veya başka birşey

[Eren Senelmis]

Merhaba,

3-tier uygulamalar'ın client tarafı (Swing) için tasarım kalıpları üzerinde bir süredir kafa yoruyoruz. Sizin düşüncelerinizi almak ve ne şekilde kullandığınızı öğrenmek istedim. Web için birçok framework var, ama Swing uygulamaları için genel geçer bir çözüm göremedik.

3-tier bir uygulamada client tarafını tasarlamak için MVC ve MVP'yi inceledik. Bunların dışında Passive View, Supervising Controller, Presentation Model gibi kavramlarla karşılaştık. Martin Fowler bu tür kavramları açıklarken "Bu konuda çalışmalar devam ediyor" şekinde not düşmüş. Yani Martin Fowler için bile konunun kesin bir çözümü yok.

Bizim için önemli olan mümkün olduğu kadar kodumuzun birim testleri ile test edilebilmesi. Dolayısıyla iş mantığımızın view'dan uzak olması gerekiyor.

Bazı kaynaklarda view'den veri çekmeye karşı çıkılıyor; binding veya benzeri bir yöntemle view'ın arkasında devamla view'la senkronize olan bir model olması gerektiği söyleniyor. Ben buna karşıyım. Senkronizasyon mekanizmasında oluşabilecek hatalardan dolayı view ile arkadaki model arasında uyuşmazlık olabilir. Hem de kullanıcının gördüğü veri ekranda dururken neden farklı bir yerde tekrar bir veri tutayımki.

Önemli bir nokta da model'den ne anladığımız. Ben modeli üzerinde hiçbir fonksiyonalite olmayan, private property'leri ve onlara ait setter/getter'ları olan sınıflar olarak kullanmıştım, sanırım iş mantığı büyük oranda model'e yıkılmalı. Ama model'in view, client, server, veritabanı arasında dolaşıp duran birşey olduğunu unutmamak gerekiyor. Bir de model'in kendisinde oluşan değişiklikleri event mekanizmasıyla view'a haber vermesinin gerektiği. Diyelim ki; view kendini model'e register etti ve daha sonra biz bu modeli persist etmek için sunucuya gönderdik. Listener'lar da onunla mı gidecek, yoksa listenerları kaybedecekmiyiz.

Açıklanması gereken diğer bir konu da veriyi kimin persist edeceği; Model mi, Controller/Presenter mı? Biz Spring kullandığımız için persistence işini interface'ler üzerinden remoting mekanizmasına gönderebiliriz. Bu, çözümü kolaylaştıran bir özellik. Ama bu durum JEE uygulamaları için sorun olabilir.

Şu an için önemli olmasa da ilerde gerekli olabilecek bir konu da; bir model'in birden fazla view'ının olması.

Bazı pattern'ler bazı sorunlara, bazı pattern'ler de başka sorunlara çözüm getiriyor. Tüm sorunları ortaya koymak için hepsini listeledim. Yukarıda saydığım sorunların tamamına çözüm getiren bir yaklaşım göremedik.

Yardımlarınız için teşekkürler

Eren Şenelmiş




------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/YazilimMuhendisligiTurkiye/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/YazilimMuhendisligiTurkiye/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:YazilimMuhendisligiTurkiye-digest@...
    mailto:YazilimMuhendisligiTurkiye-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    YazilimMuhendisligiTurkiye-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Bahri Gencsoy]

Kendi kullandığım ad-hoc sayılabilecek, ancak işe yaradığını gördüğüm
yaklaşımı açıklayayım. View'ı minimal eforla Swing'den Web'e veya konsol'a
taşıyacakmış gibi tasarlayın. Hatta bir uç adımı Unix programları gibi,
aslında konsol bazlı çalışabilecek bir programın üzerine view yazın.
Daha spesifik bir öneri ise Swing bağımlı tüm sınıflarınız bir interface'in
arkasında olsun. Bu interface'inizin implementasyonuna test yazmamayı
hedefleyerek bunların içerisinde mümkün olduğunca az test edilmesi gereken
kod bırakın. Bu zaten MVP ve Presentation Model pattern'lerinde
kullanılıyor. Passive View veya Supervising Controller patternlerini
bilmiyorum. Ancak bu yaklaşımın yukarda dediğimle de çelişebildiği durumlar
olabiliyor.

Sorunların tamamını çözen bir yaklaşım bulmak mümkün değil, "mühendislikle"
eldeki probleme uygun çözüm üretmeye çalışmak zaten işimiz.

2009/10/16 Eren <esenelmis@...>

> Merhaba,
>
> 3-tier uygulamalar'ın client tarafı (Swing) için tasarım kalıpları üzerinde
> bir süredir kafa yoruyoruz. Sizin düşüncelerinizi almak ve ne şekilde
> kullandığınızı öğrenmek istedim. Web için birçok framework var, ama Swing
> uygulamaları için genel geçer bir çözüm göremedik.
>
> 3-tier bir uygulamada client tarafını tasarlamak için MVC ve MVP'yi
> inceledik. Bunların dışında Passive View, Supervising Controller,
> Presentation Model gibi kavramlarla karşılaştık. Martin Fowler bu tür
> kavramları açıklarken "Bu konuda çalışmalar devam ediyor" şekinde not
> düşmüş. Yani Martin Fowler için bile konunun kesin bir çözümü yok.
>
> Bizim için önemli olan mümkün olduğu kadar kodumuzun birim testleri ile
> test edilebilmesi. Dolayısıyla iş mantığımızın view'dan uzak olması
> gerekiyor.
>
> Bazı kaynaklarda view'den veri çekmeye karşı çıkılıyor; binding veya
> benzeri bir yöntemle view'ın arkasında devamla view'la senkronize olan bir
> model olması gerektiği söyleniyor. Ben buna karşıyım. Senkronizasyon
> mekanizmasında oluşabilecek hatalardan dolayı view ile arkadaki model
> arasında uyuşmazlık olabilir. Hem de kullanıcının gördüğü veri ekranda
> dururken neden farklı bir yerde tekrar bir veri tutayımki.
>
> Önemli bir nokta da model'den ne anladığımız. Ben modeli üzerinde hiçbir
> fonksiyonalite olmayan, private property'leri ve onlara ait
> setter/getter'ları olan sınıflar olarak kullanmıştım, sanırım iş mantığı
> büyük oranda model'e yıkılmalı. Ama model'in view, client, server,
> veritabanı arasında dolaşıp duran birşey olduğunu unutmamak gerekiyor. Bir
> de model'in kendisinde oluşan değişiklikleri event mekanizmasıyla view'a
> haber vermesinin gerektiği. Diyelim ki; view kendini model'e register etti
> ve daha sonra biz bu modeli persist etmek için sunucuya gönderdik.
> Listener'lar da onunla mı gidecek, yoksa listenerları kaybedecekmiyiz.
>
> Açıklanması gereken diğer bir konu da veriyi kimin persist edeceği; Model
> mi, Controller/Presenter mı? Biz Spring kullandığımız için persistence işini
> interface'ler üzerinden remoting mekanizmasına gönderebiliriz. Bu, çözümü
> kolaylaştıran bir özellik. Ama bu durum JEE uygulamaları için sorun
> olabilir.
>
> Şu an için önemli olmasa da ilerde gerekli olabilecek bir konu da; bir
> model'in birden fazla view'ının olması.
>
> Bazı pattern'ler bazı sorunlara, bazı pattern'ler de başka sorunlara çözüm
> getiriyor. Tüm sorunları ortaya koymak için hepsini listeledim. Yukarıda
> saydığım sorunların tamamına çözüm getiren bir yaklaşım göremedik.
>
> Yardımlarınız için teşekkürler
>
> Eren Şenelmiş
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[cihat altuntas]

Merhaba,
Sorulariniz oldukca uzun oldugu icin parca parca cevap vermeye calisacagim.Suanda hepsini birden yanitlayacak vaktim olmadigi icin muhtemelen birden fazla post gönderecegim.

>>3-tier uygulamalar'ın client tarafı (Swing) için tasarım kalıpları
üzerinde bir süredir kafa yoruyoruz. Sizin düşüncelerinizi almak ve ne
şekilde >>kullandığınızı öğrenmek istedim. Web için birçok framework var,
ama Swing uygulamaları için genel geçer bir çözüm göremedik.

Daha önceden 2 adet büyük projede Swing+Servlet, Swing+J2EE teknolojileri kullanarak proje geliştirmiştik. Uyguladığımız pattern, mimari ve  yöntemlerden kısaca bahsedeyim umarım faydası dokunur. Projelerde ağırlıklı olarak MVP, MVC iki tasarım kalıbını genel olarak kullandık. Projede TDD ile geliştirme yaptığımız için test işlemini oldukça kolaylaştıran MVP türevlerini(Passive View,Presentation Model) daha çok kullandık diyebilirim.Tabi bunun dışında, Application Controller, Event Aggregator.. gibi pattern'lar da işimizi oldukça kolaylaştırdı diyebilirim. Presentation Model'ı da projenin bazı yerlerinde kullandık. Swing'de model ile view'ı bağlamak için JGoodies Binding kütüphanesini kullandık.

Burada model'in ne olduğu biraz karmaşıklaşıyor. Projeye göre model hiçbir business logic içermeyen DTO diğer adıyla ViewModel'de olabilir ya da Business logic içeren Domain Model nesneleride olabilir. Burada seçim mimarinize göre biraz şekilleniyor. Bulunduğum projelerde ikisinide kullandık diyebilirim. ViewModel(DTO) kullandığımız yerlerde Servis sınıfları aracılığı ile Presenter, Controller sınıflarından DTO'yu alıp gerçek nesneye çevirme ya da direk Server'a gönderip gerçek nesneler üzerinde Business Logic işlemlerini yapıyorduk.Bunun avantajları olduğu gibi dezavantajları da var. Bir defa ekstra bir DTO layer ile uğraşmak onu yönetmek zorunda kalıyorsunuz. DTO, Domain nesnesi çevirme işlemleri canınızı sıkabiliyor.... Avantajı ile View sadece ViewModel nesnelerine bağlı dolayısıyla tamamen Business Logic nesneleri ile bağlantısız.

Domain Model ile View bağladığımız durumlar da DTO'nun getirdiği ekstra layer problemi ortadan kalkıyordu fakat altyapı ile alakal bazı sıkıntılar çıkabiliyordu. Örnek olarak arka tarafta J2EE+Hibernate kullanarak Swing ekranlarına alınan Domain nesneleri session bilgisini kaybettiği için, Lazy loading ile alt nesnelere ulaşamıyorsunuz. Dolayısıyla ya eager loading yapacaksınız ya da DAO,Repository sınıflarına nesnelerin alt ilişkilerini çeken metodlar ekleyeceksiniz bu tarz problemler olabiliyordu. Ayrıca nesne detach olduğu için tekrar servera gönderildiğinde, attach, merge işlemleri gerekebiliyordu.... Şimdilik aklıma gelenler bunlar aslında bu konuda bahsedecek çok fazla şey var. Presentation Patterns konusu oldukça geniş bir konu. Diğer sorularınıza birkaç post ile tekrar cevap vermeye çalışacağım...




________________________________
From: Eren <esenelmis@...>
To: YazilimMuhendisligiTurkiye@...
Sent: Fri, October 16, 2009 7:28:46 PM
Subject: [YazMuhTR] MVC, MVP veya başka birşey

Merhaba,

3-tier uygulamalar'ın client tarafı (Swing) için tasarım kalıpları üzerinde bir süredir kafa yoruyoruz. Sizin düşüncelerinizi almak ve ne şekilde kullandığınızı öğrenmek istedim. Web için birçok framework var, ama Swing uygulamaları için genel geçer bir çözüm göremedik.

3-tier bir uygulamada client tarafını tasarlamak için MVC ve MVP'yi inceledik. Bunların dışında Passive View, Supervising Controller, Presentation Model gibi kavramlarla karşılaştık. Martin Fowler bu tür kavramları açıklarken "Bu konuda çalışmalar devam ediyor" şekinde not düşmüş. Yani Martin Fowler için bile konunun kesin bir çözümü yok.

Bizim için önemli olan mümkün olduğu kadar kodumuzun birim testleri ile test edilebilmesi. Dolayısıyla iş mantığımızın view'dan uzak olması gerekiyor.

Bazı kaynaklarda view'den veri çekmeye karşı çıkılıyor; binding veya benzeri bir yöntemle view'ın arkasında devamla view'la senkronize olan bir model olması gerektiği söyleniyor. Ben buna karşıyım. Senkronizasyon mekanizmasında oluşabilecek hatalardan dolayı view ile arkadaki model arasında uyuşmazlık olabilir. Hem de kullanıcının gördüğü veri ekranda dururken neden farklı bir yerde tekrar bir veri tutayımki.

Önemli bir nokta da model'den ne anladığımız. Ben modeli üzerinde hiçbir fonksiyonalite olmayan, private property'leri ve onlara ait setter/getter'ları olan sınıflar olarak kullanmıştım, sanırım iş mantığı büyük oranda model'e yıkılmalı. Ama model'in view, client, server, veritabanı arasında dolaşıp duran birşey olduğunu unutmamak gerekiyor. Bir de model'in kendisinde oluşan değişiklikleri event mekanizmasıyla view'a haber vermesinin gerektiği. Diyelim ki; view kendini model'e register etti ve daha sonra biz bu modeli persist etmek için sunucuya gönderdik. Listener'lar da onunla mı gidecek, yoksa listenerları kaybedecekmiyiz.

Açıklanması gereken diğer bir konu da veriyi kimin persist edeceği; Model mi, Controller/Presenter mı? Biz Spring kullandığımız için persistence işini interface'ler üzerinden remoting mekanizmasına gönderebiliriz. Bu, çözümü kolaylaştıran bir özellik. Ama bu durum JEE uygulamaları için sorun olabilir.

Şu an için önemli olmasa da ilerde gerekli olabilecek bir konu da; bir model'in birden fazla view'ının olması.

Bazı pattern'ler bazı sorunlara, bazı pattern'ler de başka sorunlara çözüm getiriyor. Tüm sorunları ortaya koymak için hepsini listeledim. Yukarıda saydığım sorunların tamamına çözüm getiren bir yaklaşım göremedik.

Yardımlarınız için teşekkürler

Eren Şenelmiş




------------------------------------

Yahoo! Groups Links




     

[Emre Suren]

Merhaba;

DB2 da Java Routine yazmayi deniyorum.

public class Hello extends COM.ibm.db2.app.UDF {

    public static String deneme(String a) throws Exception{
        return a + " 123";
    }
}


Derledikten sonra jar olusturuyorum.

CALL sqlj.install_jar('file:/home/emre/dev/java/Hello/Hello.jar','MYHELLOJAR')

ile ortama aktariyorum.

Daha sonra function i create ediyorum

CREATE FUNCTION MYDB2FUNCT(VARCHAR(200))
RETURNS  VARCHAR(200)
NOT FENCED
EXTERNAL NAME 'MYHELLOJAR:Hello!deneme'
LANGUAGE JAVA
PARAMETER STYLE db2general;

Basarili bir sekilde olusturduktan sonra, kullanmayi deniyorum

select MYDB2FUNCT('emresuren') from sysibm.sysdummy1

burada hata veriyor

DB2 Database Error: ERROR [42724] [IBM][DB2/NT] SQL4304N  Java stored procedure or user-defined function "MYSHEMA.MYDB2FUNCT", specific name "SQL091018150940400" could not load Java class "Hello", reason code "1".  SQLSTATE=42724

bazen duruma gore bazen de alttaki hatayi aliyorum

DB2 Database Error: ERROR [42724] [IBM][DB2/NT] SQL4306N  Java stored procedure or user-defined function
"MVA3.MYMD5", specific name "SQL091017152047100" could not call Java method "deneme",
signature "(Ljava/lang/String;".  SQLSTATE=42724


Arastirdim ama tatminkar bir bi;gi bulamadim, cozum icin yazilanlari denedim sonuc ayni.

NOT: DB2 da java path ayarli.

Iyi gunler.


________________________________

-- Emre Süren