4. MVC Geliştirme (Model – Görünüm – Denetleyici)

Bir web uygulaması genellikle 3 katmanlı bir mimariye sahiptir:

[dao] katmanı, genellikle bir SGBD içinde kalıcı olan verilere erişimden sorumludur. Ancak bu veriler sensörlerden, ağdan vb. kaynaklanan veriler de olabilir.
[metier] katmanı, uygulamanın "iş" algoritmalarını uygular. Bu katman, kullanıcı arayüzünün herhangi bir biçiminden bağımsızdır. Bu nedenle, hem konsol arayüzü, hem web arayüzü, hem de zengin istemci arayüzü ile kullanılabilmelidir. Dolayısıyla, web arayüzü dışında, özellikle de konsol arayüzü ile test edilebilmelidir. Genellikle mimarinin en kararlı katmanı budur. Kullanıcı arayüzü değiştirilse veya uygulamanın çalışması için gerekli verilere erişim şekli değiştirilse bile bu katman değişmez.
[interface utilisateur] katmanı, kullanıcının uygulamayı yönetmesine ve uygulamadan bilgi almasına olanak tanıyan (genellikle grafiksel) arayüzdür.

İletişim soldan sağa doğru gerçekleşir:

kullanıcı, [interface utilisateur] katmanına bir istek gönderir
Bu talep, [interface utilisateur] katmanı tarafından biçimlendirilir ve [métier] katmanına iletilir
Bu talebi işlemek için [métier] katmanının verilere ihtiyacı varsa, bu verileri [dao] katmanından ister
Sorgulanan her katman, kullanıcıya nihai yanıt verilene kadar yanıtını solundaki katmana iletir.

[métier] ve [dao] katmanları normalde Java arayüzleri aracılığıyla kullanılır. Dolayısıyla, [métier] katmanı, [dao] katmanından yalnızca arayüzünü veya arayüzlerini bilir; bunları uygulayan sınıfları ise bilmez. Katmanlar arasındaki bağımsızlığı sağlayan da budur: [dao] katmanının uygulamasını değiştirmek, [dao] katmanının arayüz tanımına dokunulmadığı sürece [métier] katmanını hiçbir şekilde etkilemez. Aynı durum, [interface utilisateur] ve [métier] katmanları arasında da geçerlidir.

MVC mimarisi (Model – Görünüm – Denetleyici), [interface utilisateur] katmanı bir web arayüzü olduğunda bu katman içinde yer alır:

Bir istemciden gelen isteğin işlenmesi aşağıdaki adımlara göre gerçekleşir:

müşteri, denetleyiciye bir istek gönderir. Denetleyici, tüm müşteri isteklerini alır. Burası, uygulamanın giriş kapısıdır. MVC'teki C'dir.
C denetleyicisi bu talebi işler. Bunu yapmak için iş katmanının yardımına ihtiyaç duyabilir. Müşterinin talebi işlendikten sonra, bu işlem çeşitli yanıtları tetikleyebilir. Klasik bir örnek şudur:
- istek düzgün bir şekilde işlenemediğinde bir hata sayfası
- aksi takdirde bir onay sayfası
denetleyici, müşteriye gönderilecek yanıtı (= görünüm) seçer. Müşteriye gönderilecek yanıtın seçilmesi birkaç adımdan oluşur:
- yanıtı oluşturacak nesneyi seçmek. Buna V görünümü denir; MVC'teki V harfi budur. Bu seçim genellikle kullanıcının talep ettiği eylemin yürütülme sonucuna bağlıdır.
- Bu yanıtı oluşturmak için ihtiyaç duyduğu verileri ona sağlamak. Aslında bu yanıt, çoğu zaman denetleyici tarafından hesaplanan bilgileri içerir. Bu bilgiler, görünümün M modeli olarak adlandırılan şeyi oluşturur; MVC'teki M harfi budur.
- Dolayısıyla 3. adım, bir V görünümü seçmek ve bunun için gerekli M modelini oluşturmaktan ibarettir.
Denetleyici C, seçilen görünümün görüntülenmesini ister. Bu, çoğu zaman müşteriye yanıtı oluşturmakla görevli görünüm V’nin belirli bir yönteminin çalıştırılmasını gerektirir. Bu belgede, hem müşteriye yanıtı oluşturan nesneyi hem de bu yanıtın kendisini “görünüm” olarak adlandıracağız. MVC literatürü bu konuda açık değildir. Eğer yanıtın “görünüm” olarak adlandırılması gerekseydi, bu yanıtı üreten nesneye “görünüm oluşturucu” denilebilirdi.
V görünüm oluşturucu, müşteriye göndermesi gereken yanıtın dinamik kısımlarını başlatmak için denetleyici C tarafından hazırlanan M şablonunu kullanır.
Yanıt, müşteriye gönderilir. Yanıtın tam biçimi, görünüm oluşturucuya bağlıdır. Bu, bir HTML akışı, PDF, Excel dosyası vb. olabilir.

MVC web geliştirme metodolojisi, mutlaka harici araçlara ihtiyaç duymaz. Böylece, basit bir JDK ve web geliştirmenin temel kütüphaneleriyle MVC mimarisine sahip bir Java web uygulaması geliştirilebilir. Basit uygulamalar için kullanılabilecek bir yöntem şöyledir:

denetim, tek bir servlet tarafından sağlanır. Bu, MVC'teki C'dir.
İstemciden gelen tüm istekler bir action özniteliği içerir; örneğin (http://.../appli?action=liste).
"action" özniteliğinin değerine göre, servlet, [doAction(...)] türünde bir iç yöntemi çalıştırır.
[doAction] yöntemi, kullanıcı tarafından talep edilen eylemi gerçekleştirir. Bunun için gerekirse [métier] katmanını kullanır.
Yürütme sonucuna göre, [doAction] yöntemi, görüntülenecek JSP sayfasını belirler. Bu, MVC modelinin V görünümüdür.
JSP sayfası, servlet tarafından sağlanması gereken dinamik öğelere sahiptir. [doAction] yöntemi bu öğeleri sağlayacaktır. Bu, MVC'in M'si olan görünüm modelidir. Bu şablon genellikle istek bağlamına (request.setAttribute("anahtar", "değer")) yerleştirilir; daha nadiren de oturum veya uygulama bağlamına yerleştirilir. Bir JSP sayfası bu üç bağlama da erişebilir.
[doAction] yöntemi, yürütme akışını seçilen JSP sayfasına aktararak görünümü görüntüler. Bunun için [getServletContext() .getRequestDispatcher(" pageJSP ").forward(request, response)] türünde bir komut kullanır.

Bu mimari deseni (Design Pattern) MVC, "Front Controller" modeli veya tek denetleyici modeli olarak adlandırılır. Tek bir servlet, tüm kullanıcıların tüm isteklerini işler.

Önceki web uygulamasının mimarisine geri dönelim:

Bu mimari, aşağıdaki n-tier mimarisine karşılık gelir:

Aslında tek bir katman vardır, o da web arayüzü katmanıdır. Genel olarak, servletler ve sayfalar üzerine kurulu bir MVC web uygulaması şu mimariye sahip olacaktır:

Basit uygulamalar için bu mimari yeterlidir. Bu türden birkaç uygulama yazdığımızda, iki farklı uygulamanın servletlerinin:

kullanıcı tarafından talep edilen eylemi işlemek için hangi [doAction] yönteminin çalıştırılması gerektiğini belirlemek için aynı mekanizmaya sahip olduklarını fark ederiz
Aslında bu yöntemlerin içeriği dışında hiçbir farkları yoktur: [doAction]

Bu durumda şu eğilim oldukça güçlüdür:

işlemi (1) onu kullanan uygulamadan bağımsız, genel bir servlet içinde faktörlere ayırmak
işlemi (2), genel servlet hangi uygulamada kullanıldığını bilmediğinden, harici sınıflara devretmek
bir yapılandırma dosyası yardımıyla, kullanıcı tarafından talep edilen eylem ile bunu işlemesi gereken sınıf arasında bağlantı kurmak

Geliştiricilere yukarıdaki kolaylıkları sağlamak amacıyla, genellikle "çerçeveler" olarak adlandırılan araçlar ortaya çıkmıştır. Bunların en eskisi ve muhtemelen en bilineni Struts'tur (http://struts.apache.org/). Jakarta Struts, Apache Yazılım Vakfı'nın bir projesidir (www.apache.org). Bu çerçeve, (http://tahe.developpez.com/java/struts/) adresinde açıklanmaktadır.

Daha yakın zamanda ortaya çıkan Spring çerçeve (http://www.springframework.org/), Struts’a benzer olanaklar sunar. Kullanımı birçok makalede (http://tahe.developpez.com/java/springmvc-part1/) açıklanmıştır.

Şimdi, servlet ve JSP sayfalarına dayalı bir MVC mimari örneği sunacağız.