Nasıl bu uygulamayı modeli istiyorsunuz?

3 Cevap php

Ben bir Oracle 10g veritabanı ve görüntüler Tablolar ve Listelerinde bu veri veri çeker ve görsel renk ve grafikleri ile bu verileri zenginleştirir Zend Framework ile yazılmış bir MVC uygulama var. Orada hiçbir ORM ve hayır, Güncelleme Oluştur veya tutulan, sadece saf Okuma silin. Veriler başka bir uygulamaya sokulmaktadır. DB veri temsil ettikleri kavramları sonra modellenmiştir ve (eski, değiştiremezsiniz) çeşitli diğer tablolardan bu verileri toplamak DB İzlenim erişilir, örneğin

| Event ID | Start               | End                 | Status | Created_By |
-----------------------------------------------------------------------------
| 12345678 | 2009-10-01 12:00:00 | 2009-10-01 12:15:00 | booked | John Doe   |
| 12345679 | 2009-11-01 13:00:00 | 2009-12-01 12:00:00 | booked | John Doe   |
| 12345680 | 2009-11-01 13:00:00 | 2009-12-01 12:00:00 | tba    | Jane Doe   |

Kullanıcılar, sipariş ve adlı işletmeye sıralama, sütun ekranı etkileyebilir. Müşteriler sütunlar ve bazı değerlere sınırı sütun içeriğe erişime izin / inkar edemez. Kullanıcılar, istemci ayarlarını geçersiz kılamaz. Bir istemci temelde müşteriye ait bir kullanıcı için mevcut verilerin bir alt kümesini oluşturur sadece bir filtre ise bir kullanıcı, bir aktör. Kullanıcı ve İstemci ayarları kalıcı.

Benim şu anki yaklaşımı kabaca şöyle çalışıyor:

Request --> Controller
            | <--> sanitizes and returns Request params
            | ---> Facade (capsules steps to fetch View Data)
            |      | <--> Table Data Gateway builds Query for requested View
            |      | <--> Query Decorator¹ applies User/Client settings
            |      | <--> DB Adapter fetches RecordSet from decorated Query
            | <----returns Recordset
            | <--> applies RecordSet to View
            | <--> Data-Aware ViewHelper render RecordSet (and View)
Response <--returns rendered View

¹ The Query Decorator can read in the persisted User/Client settings and add it to the basic Query object returned by the TDG on the fly.

Ancak, son zamanlarda ben bu yaklaşımı şüphe ve bunu geliştirmek isteyen oldum. Ben tamamen TDGS çıkarın ve UI Görünüm bina tamamen genel yapabilir sanırım; yalnız DB yapısına dayalı. Kullanıcılarının kesinlikle bu istiyorum. Şey Görünüm veriler hakkında bir şey bilmek zorunda olduğunu. ViewHelpers verileri zenginleştirmek ve genellikle Recordsets birden çok sütun açısından bunu yapmak için sütun adlarını bilmek zorunda. Onlar genel olamaz ve bir şey bu zaten sorun olduğunu söylüyor. Bu karışıklık gibi hissediyor. Ben sadece neden kesin olamaz.

Herhangi desenler, fikirler - ve görüşler - büyük takdir edilmektedir. Ben soru biraz belirsiz olduğunu biliyorum, ama dediğim gibi, bana bu yaklaşımı şüphe kılan kesin olamaz. Ben de iyi bir uygulama arıyorum sanırım bir sürdürülebilir şekilde kullanıcı ve müşteri özelleştirilebilir veritabanı merkezli uygulamaları oluşturmak için yaklaşır. Ben kesinlikle, sadece bazı fikirler ve belki diğer insanlar bu sorunu yaklaşım nasıl görmek için birkaç bağlantı bir çözüm gerekmez, bu yüzden bir sonraki üstlenmeden üzerinde bunu dikkate alabilir.

Note
I'll leave the question open for the full duration before accepting an answer. Any input is appreciated.

3 Cevap

Sorunuzu bir kaç kez yeniden okuma ve biraz üzerine yansıtan sonra, ben thusly durumu özetlemek inanıyorum:

The "M" is missing from your "MVC".

Bu noktada, bu etki alanı modeli ile 1:1 eşleme sahip böyle bir ilişkisel veritabanı şemasını el yapımı ettik. O büyük ve bu haritalama çok kolay, ama bir Recordset hala bir etki alanı sınıf değildir.

MVC bağlamında terimi, Model belirtir a domain model, bir relational model. Eğer bu uygulamayı destekleyen bir ilişkisel veritabanı varsa, o zaman haritalama çeşit gerekir. Ben bu araçları hatta küçük projeler için, benim hayat çok daha kolay hale bulabilirsiniz rağmen - - Bu Doktrin'e gibi tam teşekküllü bir ORM çerçeve gerekir demek değil ama something gerekir. Aslında, Zend Framework bile Quick Start bir etki alanı modeli eşleme hakkında uzun detaya gider.

Ben TDG kaldırmak gerekir sanmıyorum. Soyutlamalar iyi. Uygulama biraz daha yalın yapmak için dışarı müthiş ben bir ofis binası içine gidiyor ve çalışanlar sadece kendi cep telefonu kullanmak olduğunu gerekçesiyle telefon sistemini sökmek karşılaştırmak istiyorsunuz şeydir. Onlar can, ama bunu değil want Onları size görünümler veritabanına direk olarak SQL sorguları atma istemiyorum, aynı şekilde. Bu verimsiz ve yönetmek genellikle zordur.

Mimarlık benim sürümü bu gibi görünecektir:

Request --> Controller
            | <--> sanitizes and returns Request params
            | ---> Facade (encapsulates steps to fetch View Data)
            |      | <--> Table Data Gateway builds Query for requested View
            |      | <--> Query Decorator applies User/Client settings
            |      | <--> DB Adapter fetches RecordSet from decorated Query
***         |      | <--> Mapping layer converts RecordSet to Domain Model
***         | <----returns Model
***         | <--> applies Model to View
***         | <--> Data-Aware ViewHelper render Model (and View)
Response <--returns rendered View

I *** ile değişim satırları işaretledim. Gerçekten, ben değiştim tek şey yerine cephesinin bir kayıt kümesi toplayıp, bir modeli (etki alanı sınıfları olasılıkla bir dizi) toplayıp, ve View that uygulayarak olmasıdır.

Bunun yerine $row['Status'] sizin Görünümü [Yardımcı] gibi terimlerin, size uzun vadede korumak için daha güvenli ve daha basit olan, $event->status olacak. Orada hiçbir sütun adı, sadece bir özellik.

Şimdi açıkça herhangi bir ORM yok senin sorunun çok üstünde belirtildiği, bu yüzden muhtemelen bu en ve belki de sadece bir itme gerekli farkındayız düşünüyorum. What if it's not always read-only? What if the data model becomes more complicated? What if people start asking for more complicated reports?: Kafanızda bu nagging şüpheler muhtemelen çizgisinde

Bütün bunlar bir etki alanı modeli, neden neden neden aslında MVC temel yapı taşı var: Sonunda, zihinsel modeli kullanıcıların will için, veri modeli ile senkronize kalkmak var Burada içine almazsınız nedenlerle bir dizi. Nokta hemen hemen her zaman olur, bir.

Am I sure that this is necessary? Am I positive that it's not just overkill, a bunch of ritual incantations that have no meaning for such a small project?

Hayır, ben değilim. Sadece karar verebilir. Ne can size bir specific mimari olarak MVC paradigma uygun bir etki alanı modeli olmadan size çok iyi yapıyor olmasıdır. Bu sadece inline sorguları veya her sayfada cephe çağrıları zorunda daha iyi biraz daha iyi, ama that. Bir model, MVC bir fantezi URL yeniden yazma düzeni çok daha fazla değil.

Belki belki de yok, soyutlama düzeyine ihtiyaç; ama aksi takdirde soru sordu olmazdı, muhtemelen olabilir şüpheli olduğunu tahmin ediyorum. Bir düşünün, mevcut şartları ve kapsamını analiz, olası değişikliklerin ne tür kendinize sorun ve güncel mimari o karşılamak için çok kırılgan görünüyor, sonra bir sonraki mantıklı adım bir etki alanı modeli olacak - bile {[(0) ]} bu ilişkisel modelin sadece tam bir ayna bulunuyor. Yarın olmayabilir.

Bu aradığınız cevap tür olduğunu umuyoruz!

DB şema tasarım (insanların çalışma biçimini veya süreçlerin nasıl işlediğini destekleyen, iyi bir sayfa akışı) bir güzel UI olarak (sorgu / performans, ölçeklenebilirlik yazmak) farklı gereksinimleri vardır. Oldukça sık bu nedenle UI ve DB yaklaşım doğrudan harita zordur.

Kötü bir örnek olarak ben, doğrudan veritabanı yapısı genel bir görünüm sunuyordu 'Oracle Forms' kullanılarak bir uygulama hatırlamıyorum. Non-teknik okul millet için sık sık kullanmak çok sezgilere oldu.

Hala Görünüm doğrudan DB şema eşlenebilir eğer senin durumunda, emin gereksiz soyutlama-katmanları, kod kurtulmak ve sistemi basitleştirmek düşünüyorum. Olabildiğince basit gereklerini uygulamak.

Kullanıcı girişi dayalı tablodan dinamik veri almak için size Zend_Dojo bileşenleri veri ızgara kullanabilirsiniz. Siz kullanıcı girişi dayalı yeni bir tablo eşlediniz bir TDG nesnesi oluşturabilirsiniz.

http://zendguru.wordpress.com/2009/01/08/dojo-grid-in-zend-framework-creating-nice-and-cool-grid-in-php-using-zend-framework-and-dojo/

etiketler