PHP MVC &

3 Cevap php

Ben MVC ile ilgili çeşitli makaleleri okuma ve birisi muhtemelen yanıtlayan bana yardımcı umuyordum bir kaç soru vardı oldum.

MODEL veri temsili ve bu verileri işlemek için bir araçtır Öncelikle eğer, o zaman ortak bir arayüzü kullanarak soyutlama belirli bir düzeyde bir veri erişim nesnesi (DAO) çoğu görev için yeterli olmalıdır gerekir değil?

(Yani UNIX_TIMESTAMP) - - benim SQL tabloların yapımında ve bir soyut kullanılan daha bu noktada ayrıntılı için, ben satıcı belirli işlevleri kaçınılmalıdır eğer benim geliştirme çoğu, benim veriler için temel depolama mekanizması olarak MySQL ile yapılır demek MySQL ve belki PostgreSQL veya MySQL ve SQLite arasında hareket ortak bir arayüze sahip DB nesne, basit bir süreç olmalıdır.

İşte bazı görevi de alıyorum ne, bir tek CONTROLLER tarafından işlenir - (yani UserRegistration) ve yerine bir MODEL bu görev için oluşturarak, ben bir örneğini getirebilirsin db nesne - (yani DB :: getInstance ()) - Daha sonra gerekli db yeni bir kullanıcı INSERT aramaları yapmak. Neden böyle basit bir görev ile yeni bir yaratacak MODEL?

Bazı örneklerde bir MODEL oluşturulur gördüm, ve o içindeki MODEL sipariş tablosundan siparişlerin x sayıda alınır ve bir dizi döndüren bir SELECT deyimi var. Neden bunu, eğer sizin CONTROLLER senin bu dizi üzerinden yineleme ve VIEW atamak için başka bir döngü oluşturarak; ex. 1?

ex. 1: foreach ($list as $order) { $this->view->set('order', $order); }

Böyle bir şey muhtemelen bu yüzden bir dönüşünü değiştirmek sanırım; ex. 2.

ex. 2: while ($order = $this->model->getOrders(10)) { $this->view->set('order', $order); }

Benim argüman basitçe CONTROLLER içinde gerekli db arama yapabilirsiniz zaman neden web sitelerinin çoğu şüpheli olarak, sizin verilerinize erişmek için ortak bir arayüz ile bir DB nesnesi kullanarak varsayarak, bir model oluşturmak olduğunu tahmin kullanıyorsunuz. Yapılıyor ne çoğu mutlaka ayrı bir MODEL garanti değil yeterince basit olduğunda Evet ben yine bu tüm görev için pratik bekliyoruz, ama yok.

Bir kullanıcı bir istek 'www.mysite.com/Controller/action/args1/args2' yapar hemen duruyor gibi, ön denetleyicisi (Ben yönlendirici diyoruz) Controller (sınıf) kapalı geçen ve denetleyici içindeki belli bir eylem ( yöntemi) olarak adlandırılır ve oradan uygun VIEW oluşturuldu ve daha sonra çıkarılır.

3 Cevap

Yani bir model katman-bir veritabanı erişim nesnesi üst-katma karmaşıklığı gitmek istediğiniz yol olup olmadığını merak ediyorsanız sanırım. Benim durumumda, basitlik başka endişe koz, bu yüzden tamamen bir model olmadan gitmek ve veri erişim bir kontrol eşdeğer meydana sahip basittir net bir durum görürseniz, o zaman o ile gitmek gerektiğini öneririm.

Ancak, MVC ayrımı olan hala diğer potansiyel faydaları vardır:

  • Denetleyicisi hiç SQL: Belki (? Sadece başka bir şey, bir dosya test için bir alay nesnesi oturumda bir dizi), ya da veritabanı şema değişiklikleri bir veritabanı dışındaki bir kaynaktan gelen verileri toplamak için karar ve kodunuzu değiştirmek için sahip olduğu tüm yerlere bakmak zorunda, sadece modeller üzerinden bakmak olabilir.
  • Skillsets ayrılığı: Belki takımda birisi karmaşık SQL sorguları büyük, ama php tarafı ile ilgili de büyük değil. Sonra daha fazla kod (o şeylerin html / css / javascript tarafına gelince daha çok) daha fazla kişi güçlerini oynayabilirsiniz olduğunu ayrıldı.
  • Bir veri bloğunu temsil kavramsal nesne: Steven dediği gibi, veritabanı olmaktan almak faydaları bir fark var agnostik (yani ihtiyaç varsa mysql ve postgresql arasında geçiş yapabilirsiniz) ve varlık schema agnostik (yani Eğer farklı ilişkisel tablo geldi bile), birlikte iyi uyan verilerin tam bir nesne var. Eğer verilerin iyi bir bloğu temsil eden bir model varsa, (bir personel listesi görüntülenirken, örneğin bir kişilik modeli oturumları kullanılabilir ve olabilir) birden fazla yerde bu modeli yeniden gerekir.

Ben kesinlikle MVC görevlerin ayrılığı idealleri çok yararlı olduğunu düşünüyorum. Ama zamanla bir fonksiyonel programlama stili ile MVC gibi ayrılık, bir tam şişmiş cepten MVC sistemi daha php ile başa çıkmak için daha kolay olabilir tutmak gibi bu alternatif stilleri, düşünmek için geldim.

Ben soruların çoğu ele bu büyük yazı bulundu. Durumda herkesten benzer sorular vardı ya da bu makaleyi okuduktan ilgileniyor. Sen burada bulabilirsiniz http://blog.astrumfutura.com/archives/373-The-M-in-MVC-Why-Models-are-Misunderstood-and-Unappreciated.html.

MVC arkasındaki fikir, mantık arasında temiz bir ayrım sahip olmaktır. Yani görünüm sadece çıkış olduğunu ve denetleyici modelleri ile etkileşim ve gerekli görüşlerini vermek için gerekli verileri almak için modelleri kullanarak bir yoludur. Ama aslında veri alma tüm iş modeliniz devam edecek.

Eğer gerçek bir kişi değil, bir veri parçası olarak Kullanıcı model düşünüyorsanız. Eğer kişilerin isim daha kolay telefon (veritabanı) üzerinde bir merkez ofis çağırmak ve adını istemek ya da sadece, kişiye sormak olduğunu bilmek istiyorsanız "Adın ne?" Bu modelin arkasındaki fikir biri. ? Bu sayfayı görüntülemek için size ne tür kaydediliyor - en basit şekilde gerçek canlıların ve sizin kontrolörleri bu canlıları bir dizi soru (IE sormak için izin onlara eklemek yöntemler olarak modellerini görebilirsiniz son değiştirilme zaman görüntü sen? sen? yayınlanır?). Sizin kontrolör aptal olmalı ve modeli akıllı olmalıdır.

Diğer fikir, bu durumda sizin modelleri, tek bir merkezi konumda SQL iş tutmaktır. Eğer hatalı sizin denetleyicileri etrafında yüzen SQL ve (en kötü senaryo) görüşleriniz yok ki.