Bir rehber gibi basit bir web sitesinin programlanmasında iyi (düzgün) mimari nedir?

Basit bir web sitesi kurduğumda, örneğin kişileri ekleyebildiğim, silebileceğim ve güncelleyebileceğim bir rehber gibi, index.phpgiriş yapmamışsa, bir şifre girmesi istendiğinde ve doğru şifreyi girdiğinde bir dosya oluşturdum. bir oturum atadı ve rehber ile belirli şeyler yapabilirsiniz.

İki dosyam var:

1. İlki ( contacts.php) gösterilecek HTML kodudur. HTML kodunun üzerinde ikinci dosyayı ekledim ve sınıfı oluşturdum.
2. Second ( contacts_class.php), ekleme, silme ve güncelleme için tüm yöntemleri içerir.

Bence sorun değil, ama büyük bir projeyi hayata geçirme konusunda, nasıl yapmalıyım? Her sayfa için klasörler oluşturmalı mı ve içine dosya koymalı mıyım (yukarıdaki gibi, HTML ve sınıf) ve nasıl yapmalıyım? Diğer programcıların anlayabileceği büyük projeler oluşturmak için iyi ve düzenli bir mimari nedir?

Çok ilginç ve temel bir soru sordun. Büyük ölçekli proje mimarisi ve klasör yapısı organizasyonu ile ilgili soru (mimariye ikincildir).

Bugün, CMS çerçeve mimarisini oluşturmaya yönelik en yaygın yaklaşım, MVC şablonunun kullanılmasıdır. Kendi MVC çerçevelerinizi oluşturma hakkında bazı iyi makaleler var, bunlardan biri PHP ile bir MVC Çerçeve Oluşturma .

MVC, Model, Görünüm ve Kontrolör anlamına gelir. Bu yaklaşımları istediğiniz gibi çağırabilirsiniz - MVC, HMVC, MVP. Temel, sisteminizin ayrı bileşenlerini izole etmektir. "Kontrolör", verileri "Model" den alır ve son HTML'yi veren "Görünüm" e gönderir. "V" yi kendi contacts.phpdilinizde ve "MC" yi kendi dilinizde uyguladınız contacts_class.php. Yani görünümü modelden ve kontrol cihazından izole ettiniz. Artık diğer parçaları sağlam bırakarak "Görünümünüzü" kolayca değiştirebilirsiniz.

MVC'yi, MVP'yi veya başka bir "MV" modelini körü körüne takip etmenizi önermiyorum. Uygunluk, etkinlik ve lezzet meselesidir.

Ortak dinamik web sitesi uygulaması, aşağıdaki gibi bileşenleri içerebilir:

• Giriş noktası index.php
• Yardımcı kütüphaneler / sınıflar
• İstek yönlendirici
• Modüller, bileşenler veya kontrolörler
• Şablon motoru veya belki de tek görünüm

Gerçek web uygulaması, olay işleyicileri, olay göndericileri ve kancalar gibi diğer bileşenleri içerebilir, ancak bunlar aslında nüanslardır. Peki, onu sunmak istediğim şekilde sunmama izin ver:

Aşağıdaki gibi ortak çerçeve operasyon rutini:

1. Tarayıcı isteği doğrudan çalıştırılabilir / script ( index.php) giriş noktasına gönderilir .
2. Giriş noktası betiği yardımcı kitaplıkları yükler, sınıflar ve programlama ortamımızın bazı başlangıçlarını gerçekleştirir.
3. URL, istek yönlendirici örneğine iletilir. Bu adım, 2. adımın bir parçası olabilir.
4. İstek yönlendirici URL'yi ayrıştırır ve işlemi belirli bir bileşene, modüle veya denetleyiciye gönderir.
5. Bileşen (veya denetleyici) yönlendirilen isteği işler ve verileri oluşturulacak görünüme gönderir.

Karşılık gelen proje klasörü yapısı şemada gösterilmiştir.

Diğer çerçevelerin nasıl uygulandığını araştırmanızı öneririm. Önerilen CMS / çerçeveler, CodeIgniter, OpenCart, Joomla 1.5 ve Tango CMS'dir.

Hangi soruların sorulacağı ve hangi çözümlerin mevcut olduğu hakkında bir fikir edinmek için Martin Fowler'ın Kurumsal Uygulama Mimarisi Modellerini tavsiye ederim . Web sitesinde okuyarak kitabın içinde ne olduğu hakkında bir fikir edinebilirsiniz

Lütfen kitabın çok eski (IT ülkelerinde) eski olduğunu, ancak birçok ilkenin hala geçerli olduğunu veya bunları öğrenmek için öğrenmeniz gerektiğini unutmayın. (Bu mantıklı mıydı?)

(Yazılım) Mimarlık çok geniş bir konudur, gümüş bir mermi beklemeyin ama zaman ve para tükenene kadar her zaman daha fazla soru ve daha fazla şüphe ve şimdiye kadar en iyi çözüme bağlı kalmak zorundasınız.

Her şeyden önce, iyi gelişmiş bir projeye göz atın. Wordpress, kod yapısının çok temiz bir örneğidir: anlaşılması basittir ancak birçok "fiş" sunar. Yani wordpress "plug in" ile tahmin etmek kolaydır.

İkincisi, mimarinizi kontrol etmenin çok kolay bir yolu ünite testi yazmaya çalışıyor. Örneğin, "Card Deck" sınıfı "shuffle ()" yöntemine sahipse, önceden tanımlanmış boyutta bir Card Deck oluşturabilir (ör. 5 kart 1,2,3,4,5), karıştırmayı çağırabilir ve bir kolay yol sonucu (id 1,4,2,5,3)

Tüm proje sınıflarını başlatmadan bunu yapabilmelisiniz ve testin okunması çok temiz olmalı.

Bunu yapamazsanız, sınıflar arasına katmanlar eklemeniz, kolay bir yol bulana kadar yeniden yapılandırmanız gerekir.

Ardından, bu adımı projenizin tüm temel sınıfları için tekrarlayın.

Son fakat en az değil: iyi bir mimarlık, çekirdek olmayan sınıflarda “tembel” olabilir (bu bir ekonomi meselesi: çok iyi tasarlanmış şeyler gerçek dünyada çok pahalı).

Büyük ölçekli projeler için iyi bir mimari MVC'dir (Model View Controller): http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Bununla birlikte, diğer programcıların bunu anlayıp anlamayacağı tamamen farklı bir konudur. MVC karmaşıklaşabiliyor ve küçük projeler için bazen aşırı ısırılıyor. Bunun yararlarından biri de kolayca ölçeklenmesidir.

Sorunuzu doğru anlarsam, aslında bir mimariden değil, proje klasör yapısından bahsediyorsunuz. Anlayışım doğruysa, okumaya devam et; başkası sorunuzu düzenleyin ya da bir yorum yazın, ben de cevabımı buna göre düzenleyeceğim.

Bir uygulama tasarlarken, (ne? Ve kime?) Gibi bazı temel soruları cevapladıktan sonra, bileşenleri tanımlamamız ve işlevsellik \ sorumluluklarına göre sınıflandırmamız gerekir. Bildiğim iki ana yol var. Bileşenleri temel alarak sınıflandırabilir, ele aldıkları durumları (oturum açma, arama vb. Gibi) kullanabilir veya Kaynaklara (Nesneler ..) göre sınıflandırabilirsiniz. İlki Faaliyet odaklı, ikincisi Kaynak Yönelimli olarak adlandırılır. Geleneksel olarak çoğu uygulama, Faaliyetleri temel alan bileşenleri sınıflandırır (tasarımcılar bulduklarından beri sorunlu etki alanından çözüm etki alanına aktarırken kolay).

Bileşen sınıflandırması tanımlandıktan sonra, Tiers'e dayalı sınıflandırmayı tanımlamamız gerekir. Tipik bir web uygulamasında View Tier, Model Tier ve Controller Tier (MVC) olacaktır. Elbette daha karmaşık uygulamalar da olabilir. (çoğu gerçek dünya uygulaması, bu kadar basit olmaktan daha karmaşıktır).

Bu iki taksonomiyi belirledikten sonra, her bir Katmanı tanımlayan üst düzey klasörler oluşturacağım. (UI, Denetleyici, Hizmetler, Yardımcı Programlar vb.). Her üst seviye klasörün altında, İşlevsellik veya Kaynaklara (Project - / EditProject - / SearchProject vb.) Dayalı alt klasörler oluşturacağım. İdeal olarak fonksiyonel sınıflandırma çok seviyeli olacaktır.

İyi mimariler ve kötü mimariler var, ancak gümüş mermiler yok. Bir mimarinin mevcut ve oldukça muhtemel gelecekteki gereksinimlere uygun olması gerekir.

İyi bir rehber, uygulamanın her bir bölümünün diğer bölümler üzerinde minimum etkiye sahip olabileceğinden ve her bölümün otomatik tam kapsama ünitesi ve entegrasyon testlerine sahip olduğundan emin olmak olacaktır.

Mimarlık, uzun vadede gelişmeye devam edebileceğinizden emin olmakla ilgilidir. Daha büyük uygulamalar için bu, işleri birbirinden bağımsız kılmak, böylece birden fazla kişinin eşzamanlı çalışabilmesi ve yinelemeden (DRY) kaçınmak, böylece projenin çevik kalabilmesi için takaslar yapmayı içerir. PHP projeleri işleri bağımsız kılmaya odaklanır ve çoğaltılması önemlidir.

Diğer aşırı pozisyon için iyi bir his elde etmek için Seaside'a bakın

Büyük bir projeyi nasıl yapılandıracağınızı bilmiyorsanız, birkaç iyi PHP Çerçevesinden birini kullanarak başkalarının tasarım / mimarisini ödünç almalısınız. CakePHP, CodeIgniter veya Symfony'yi tavsiye ederim. Bunların hepsi, web geliştirmede iyi çalışan bir Model, View, Controller, MVC patenti kullanıyor, hepsi oldukça hafif ve öğrenmesi kolay.

Bu çerçevelerden birini tanıdığınızda, kendi projeniz için kendi yapınızı oluşturabilecek bir konumda olabilirsiniz, ancak yeni başlıyorsanız, tekerleği yeniden icat etmek gibi başkalarının çalışmalarına da katlanırdım.

MVC, problemlerin çoğunu çözdüğü kanıtlanan en yaygın kullanılan mimaridir. İyi bir mimari, aşağıdaki özelliklere sahip olacaktır (ve daha fazlası, orkestra)

1. Birim test edilebilir
2. Endişelerin ayrılması
3. Birden fazla halk, herhangi bir çarpışma olmadan üzerinde çalışabilecek.
4. Çok fazla sorun olmadan uzatılabilir
5. Ölçeklenebilir olabilir. Büyük projeler söz konusu olduğunda ölçeklenebilirlik büyük bir endişe kaynağı olacaktır. Ödeme Kohana iyi yazılmış ve çok iyi ölçeklenebilir çerçeve,

Herhangi bir üretim kodunu yazmadan önce 2 hafta (gece :) alır ve bu kitabı okuyun. Programlama mimarisi, pratikler ve packiging konusunda fikrinizi uzun süre değiştirecek.

Çevik İlke, Kalıp ve Uygulamaları C # Prentice Hall tarafından

Örnekler C # 'dadır ancak okunması kolaydır, doğru kod sözdiziminin nasıl yazılacağı ile ilgili değildir, bir programcı olarak nasıl düşünüleceği ile ilgilidir.

Söz veriyorum, PC'nizdeki en güvenilir yere kaydedeceğinize ve bunu bilmeden programladığınıza şaşıracaksınız. Düşünceni değiştirecek.