Modülleri / eklentileri desteklerken MVC çerçevenizi nasıl düzenlersiniz? [kapalı]

17

MVC çerçeveleri söz konusu olduğunda gördüğüm iki ana kod tabanı yapısı var. Sorun, her ikisinin de onlarla birlikte gelen bir örgütsel hataya sahip olduklarıdır.

Standart MVC

/controller
/model
/view

Sorun: İlgili bileşenlerin ayrılması yok (forum, blog, kullanıcı vb.)

Modüler MVC

/blog
    /controller
    /model
    /view
/user
    /controller
    /model
    /view
/forum
    /controller
    /model
    /view

Modül tabanlı sistemi seçmek size bir sorun çıkarır.

Uzun isimler (Forum_Model_Forum = forum / model / forum.php) (Zend gibi)
Dosya sistemi is_file()forum modelinde hangi klasörü bulmak için arama yapar ? (Kohana gibi)

Farklı modülleri ayırmaya çalışırken diğer MVC yapıları iyi çalışıyor mu? Kaçırdığım bu yapılardan fayda var mı?

— Xeoncross
kaynak

1

Ayrıca, gerekirse Zend ve Doctrine gibi kütüphaneleri de kullanabilmem için PSR-0 uyumlu bir yapı istediğimi eklemek isterim .

— Xeoncross

9

Deneyin:

/blog 
    /controller
    /view
/user
   /controller
    /view 
/forum
    /controller
    /view
/model
    User
    BlogPost
    Comment
    ....

Modelleriniz uygulamanızın kalbidir. Onları bağımsız bir paket olarak tasarlamalı ve kodlamalısınız. Denetleyiciler, kullanıcı etkinliğini modelinizin işlemlerine dönüştüren modelinizin yalnızca istemcileridir. Görünüm, modelinizden veri göstermenin yalnızca belirli bir yoludur. Uygulamanız büyürse, istemcileri modelden ayırmada daha da ileri gidebilirsiniz:

WebClient
    /blog 
        /controller
        /view
    /user
       /controller
        /view 
    /forum
        /controller
        /view
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment
    ....

Bu, bir şekilde veya başka bir şekilde, tek bir modelle etkileşime giren birden fazla istemcinizin olabileceğini açıkça göstermelidir.

— Mathias Verraes
kaynak

+1 çünkü MVC bileşenleri ve bunların nasıl çalışması gerektiği konusunda tamamen katılıyorum. Bununla birlikte, bir modülün amacı, diğer kullanıcılar tarafından oluşturulan modülleri içe aktarabilmenizdir, böylece modül yolunun dışındaki modellere sahip olmak onu daha az "sürükle ve bırak" yapar. Ancak, yönteminiz harici eklentileri veya modülleri kullanmayan uygulamalar için çok mantıklıdır.

— Xeoncross

@Xeoncross bu doğru, burada tekrar kullanılabilirliği gerçekten dikkate almadım. Bu bir gereklilikse, bir adım daha ileri gidebilir ve örneğin, Kullanıcı modelini denetleyicisiyle gruplayan bir 'Kullanıcı' modülüne ve BlogPost ve Yorum modelini denetleyicileriyle gruplayan bir Blog modülüne sahip olabilirsiniz. Her zaman olduğu gibi: bağlama bağlıdır :-)

— Mathias Verraes

2

;)

Bir MVC / HMVC Framework için en iyi yapıyı birleştirdim. Ana ünite için temel kontrolörleri / modelleri / görünümleri kullanmanız gerekir ... ancak kurs modüllerinin bireysel bileşenleri için ...

Yani benim MVC / HMVC çerçeve yapısı şöyle:

/application
  controllers/
  models/
  views/
  modules/
    blog/
      controllers/
      models/
      views/ 
    user/
      controllers/
      models/
      views/
    forum/
      controllers/
      models/
      views/

Ayrıca ihtiyacım varsa modül kitaplıkları, i18n veya yardımcıları ekleyin.

Adlandırma kuralı kolaydır, denetleyiciler ve modeller için _Controller ve _Model sonekini eklerim. Modüllerdeki kontrolörler ve modeller için ayrıca modül adıyla birlikte bir önek eklerim, örn. controller Kullanıcı modülündeki Profil User_Profile_Controller olarak adlandırılacaktır.

Bu yüzden ihtiyacınız olanı bulmak çok kolay ve hızlı.

— Shogun
kaynak

1

Sorun: Uzun isimler (Forum_Model_Forum)

Sınıfların sistematik adlandırılması, bileşenler arasındaki çakışmaların adlandırılmasını önlemeye yardımcı olur. Sınıfların uzun süre adlandırılmasının ciddi performans cezaları getirmesi olası değildir. Kodlama sırasında bu adlandırma şemasını oldukça yararlı buluyorum çünkü nereden geldiğini görmek kolay.

dosya sistemi aramaları (hangi klasörde forum modeli vardır).

Bu, sistemin nasıl uygulandığına bağlıdır, ancak dosya sisteminin yapısı genellikle kapsamlı dosya sistemi aramaları olmadan doğru bileşene anında erişim sağlayan bir kural izler.

Bir örnek, forum bileşeninin kullanılacağını varsayalım:

Bilgi:

Bileşen adı: forum
Denetleyici adı: dizin

$ controller_path = BASEDIR. 'modül /'. $ bileşen_adı. '/ denetleyici /'. $ controller_name. 'Php';

Ayrıca, tipik bir web sitesini önyüklerken tam anlamıyla yüzlerce dosya sistemi sorgusu olduğunu, bu nedenle bazı eklemenin zarar görmeyeceğini unutmayın.

— Lea Hayes
kaynak

Gerçekten, arka uçlar hızlı bir şekilde başlatılması gereken istemci tarafı uygulamalara benzemez, çalışma zamanını düzgün bir şekilde yapılandırmak için gereken zamanı alabilirler. İyi bir nokta.

— Patrick Hughes

0

İlk "Standart MVC" ile başlayan web siteleriyle çalıştım, ama sonunda "Modüler MVC" oldum.

Küçük bir web sitesi yapıyorsanız ve fazla deneyiminiz yoksa, "Standart MVC" ile başlamak isteyebilirsiniz. Web sitesinin çok karmaşık ve büyük olacağını zaten biliyorsanız, "Modüler MVC" ye alışmanız gerekecek, başlangıçta biraz zor olacak, ancak sonunda, o.

— umlcat
kaynak

0

Aslında kendim bir çerçeve üzerinde çalışıyorum ve hem modül tabanlı hem de serbest biçimli dizin yapısı bir arada kullanın. Çerçeveyi kullanarak site kodu için varsayılan yapım:

/Configuration (stored a bunch ini files for security related information like passwords)
/Functions (stores file(s) with standard procedural functions)
/Libraries (general use classes)
/Models (all models go here)
/Modules (each module refers to one controller
/Modules/Site (controller class store in this folder if there is a controller)
/Modules/Site/Views (views for the controller)

Ayrıca bir denetleyiciyle ilgili olmayan bir modül klasörünüz olabilir ve varsayılan olarak üstbilgi ve altbilgi gibi site çapında şablonları depolamak için kullanılan bir Çekirdek çağrısı vardır. Bu bana her iki dünyanın en iyisini verir. Klasör başına bir denetleyici olduğu için denetleyicinin nerede olduğunu kolayca öğrenebilirsiniz, ancak modeller gibi sınıflar için, dosyaların tek bir dizin altında olduğu gibi nerede olduklarını aramanıza gerek yoktur (bu da modellerin adlarını daha temiz tutar) .

Ben dosya yükleme yolu biraz farklıdır ben kullanıcı sınıfları olabilir nerede farklı dizinleri yapılandırmak için izin böylece başlangıçta dizinleri ayrıştırmak ve tüm sınıf dosyası konumlarını bir json dosyasında depolamak ve sonra hızlı arama için kullanmak diğer tüm istekleri (ben bunu geliştirmek için yollar arıyor olsa bile).

— ryanzec
kaynak

0

Bunun cevabı, tüm büyük sistemlerin adapte olmaya başladığı veya şimdi benimsediği PSR-0 Teklifi tarafından belirlendi .

Yapı:

\Doctrine\Common\IsolatedClassLoader => /Doctrine/Common/IsolatedClassLoader.php
\Symfony\Core\Request => /Symfony/Core/Request.php
\Zend\Acl => /Zend/Acl.php
\Zend\Mail\Message => /Zend/Mail/Message.php

Bu, uzun dosya adlarını düzeltmek için yapabileceğiniz hiçbir şeyin olmadığı anlamına gelir:

$controller = new \Blog\Controller\Archive => /Blog/Controller/Archive.php

/Blog
    /Controller
        Archive.php
    /Model
    /View
/User
    /Controller
    /Model
    /View
/Forum
    /Controller
    /Model
    /View

Bu aynı zamanda tüm küçük harfler yerine aptal karışık durum dosyalarını kullanmanız gerektiği anlamına gelir (üçüncü taraf kitaplıkları çalışmazsa).

— Xeoncross
kaynak

0

Mathiases çözümü çok mantıklı ve klasör yapısını kullanmak takılabilir içeriğe sahip olmayı engellemiyor, örneğin bir bağımsız / galeri eklemek gibi görünebilir

WebClient
    /blog 
        /controller
        /view
    /user (uses /model/User/)
       /controller
        /view 
    /forum
        /controller
        /view
    /gallery
        /controller
        /view
        /model
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment

Şimdi paylaşılan bir "model" ve gerekirse bağımsız modellere sahibiz

— Timo Huovinen
kaynak