MVC kullanımının geliştirilmesi

2 Cevap php

Ben Kohana MVC framework kullanarak PHP MVC uygulama inşa meşgulüm, ve çok iyi çalışıyor. Ama değinmek istiyorum bazı küçük can sıkma vardır.

Mantık bir çok kontrolörleri ve kontrolörleri kendilerini eylemleri karşısında tekrarlanır. Ben bunu düşünüyordum ve ben bu paylaşılan mantığı içeren bir nesneyi tanımlamak için akıllı olacağını düşündüm, bu yüzden tekrarlanan almaz.

Sonra bazı podcast görünüm-modelleri hakkında ve Preventing mission creep in your Views, or, ignorance is bliss duydum. Yani görünümü-modelleri arıyordu nelerdir.

Ama şimdi görünümü modellerin ne koymak soru geliyor. Benim fikrim ben görünümü-modeli tüm BİLGİLERİ gelen görünümü ihtiyaçlarını toplayalım oldu. Bu, her denetleyicisi / eylem sadece görünümü-model girdi verileri aktarmak ve ardından görünümüne geçmek gerekiyor avantaja sahiptir.

Bu akıllı bir fikir mi? Test behalve üzerinde, onu taklit etmek mümkün yani viewmodel modelini geçmek akıllıca olacaktır. Ama gerçekten modellerini kullanarak değilim. Yerine, ben kontrolörleri Doktrini ORM aracılığıyla veritabanına erişim sağlar. Ayrı yönteme her sorgu tercüme biraz garip görünüyordu, ama belki ben bir şey eksik.

Ben görünümü-modelleri hakkında duyduklarımı, onlar sadece düz DTO'ın demektir. Ama dinamik zayıf yazdığınız dilde bunun avantajı nedir?

Belki tamamen yanlış yolda olduğumu ve farklı yapıyor olmalıdır. Bu konuda düşünceleriniz nelerdir?

Edit:

Ben bahsediyorum mantığının en doğru bilgi toplama ve doğru görünümleri için geçiyor.

Örnek:

Ben bir müşteri denetleyicisi var. Eklemek ve düzenlemek: Bu iki eylem var. Bu iki eylem için, ben aynı görünümünü kullanın. Her iki eylemlerde görünümü için aynı değişkenler atanır. Formu geçerli değil eklenti eylem olarak, girdi değişkenleri tekrar görünümüne geçirilir. Düzenleme eylem olarak, mevcut değerler çukur geçirilir. Bu benim değinmek istiyorum büyük bir çoğaltılması olduğunu.

2 Cevap

Tekrarlanan mantık bazı üstlenmeden gerekli olduğunun bir göstergesidir, bu loic size refactor nereye kadar biz emin olamaz ne demek bilmiyorum, ama Kendinizi yararlı bir ilkedir tekrarlayın Etmeyin. Yani orijinal fikir iyidir. Acaba Controller DB (Bir Modelin eksikliği yani) çoğaltılması için neden bir parçası olduğunu için doğrudan etkileşim olup olmadığını?

Görünüm Modelleri DTOS daha vardır. Onlar (veya nokta) İş Verileri içeren ve ayrıca Alakalı yorumlama mantığı var. "Misyonu sürünme" yazıda size fikir görmek başvuru. Görünüm kendisi bir bağlantıyı görüntülemek için olup olmadığını bilmek istiyor. Bu karar iş verilerinin çeşitli parçalara dayanmaktadır. Sen basit bir showLink() yönteminde birlikte bu mantık çekin. Sonra görünümü sunum odaklanmak ve ViewModel yorumlanmasında odaklanabilirsiniz. Ve, aynı zamanda önemli, gerçek İş Verileri kendisi sunumu hakkında hiçbir fikri yok.

Kohana ile kontrolörleri tekrarlanan kod hakkında önceki paragrafta ... sizin endişe hitaben, ben genellikle bir ana kontrolöre ortak denetleyicisi kod koymak ve bundan tüm denetleyicileri devralır.

Örneğin, bir projede ben $ this-> auth olarak her sayfada Auth modülü için bir başvuru kullanılabilir hale getirmek için Template_Controller değiştirilmiş bir sürümünü kullanıyorum.

abstract class Template_Controller extends Controller {

	/* @var Auth_Core reference to authorization class */
	protected $auth;

	public function __construct()
	{
		parent::__construct();
		[snip]
		$this->auth = new Auth();
	}
[...]
}

Şimdi benim tüm kontrolörleri böyle başlar:

class Help_Controller extends Template_Controller {

Tüm kontrolörler, böylece herhangi bir işlev içinde $ this-> auth erişebilirsiniz. Görüşlerin dışında biz mantığı tutmak Katılıyorum, o bütün fikir.

etiketler