2010-01-18 10 views
5

Ich entwickle ein CMS, das weitgehend auf Zend Framework-Komponenten basiert. Einige der Datenbanktabellen für dieses CMS sind wie folgt:Granularisierung von Modellen?

site 
| id | name | 
------------- 

locale 
| languageCode | regionCode | 
----------------------------- 

site_locale // link sites with locales 
| siteId | languageCode | regionCode | isActive | isDefault | 
------------------------------------------------------------- 

Ich habe ein Modell namens Site, die unter anderem von den folgenden Verfahren besteht:

getId() 
getName() 
listLocales() // list all locales for this site 

Ich bin ein bisschen auf die Zaun, wie granularized I Modelle definieren soll:

SiteLocale Objekte/Modelle (mit anderen Worten einer DB-Tabelle Darstellung) aus dem listLocales() Verfahren, in denen diese SiteLocale Objekte

eine Option co wäre zurückzukehren Ntain der folgenden Methoden:

getSite() // returns the Site model 
getLocale() // returns a Zend_Locale 
isActive() // is this locale active for the site this model represents? 
isDefault() // is this the default locale for the site this model represents() 

Die andere Option einfach sein würde, um die folgenden Methoden in dem Site Modell zu erstellen und mit ihm getan werden:

getDefaultLocale() // simply return the default site locale as Zend_Locale 
listActiveLocales() // simply return all active site locales as Zend_Locales 
listAllLocales() // simply return all site locales as Zend_Locales 

Was fühlen Sie tun, ist der richtige Weg gehen? Und warum?

Würde darüber hinaus die erste Option (oder vielleicht sogar beide Optionen) die Law of Demeter verletzen?

EDIT (22. Januar)
Obwohl Ich mag Jeff's Antwort, Im immer noch offen für neue/andere Perspektiven.

Antwort

3

Zunächst zu den Datenbanktabellen: Sie könnten die Datenbank wahrscheinlich weiter normalisieren. Es gibt eine Duplizierung zwischen den Tabellen locale und site_locale. Natürlich sehe ich hier nicht das große Ganze, also könnte etwas dahinter stecken.

Offen gesagt, beide Optionen sind in Ordnung. Ich würde das Design wählen, das Ihren Code lesbarer und wartbarer macht. Zum Beispiel, wenn Sie die erste Option wählten, würden Sie Schleifen wie diese überall am Ende?

site_locales = site.listLocales() 
foreach (site_locale in site_locales) { 
    if site_locale.isDefault() { 
     do_something(site_locale.getLocale()) 
    } 
} 

Wenn ja, dann würde ich es vermeiden, und mit der zweiten Option gehen und am Ende mit:

do_something(site.getDefaultLocale()) 

Das ist viel besser verständlich mit einem schnellen Blick. Vielleicht würde es sogar die Leistung Ihrer Website verbessern.

Allerdings, wenn Sie denken, Sie werden eine Menge Arbeit zu tun, die Listen von SiteLocales in Zukunft verwendet, aber Sie wissen nicht genau, was Sie über getDefaultLocale(), listActiveLocales() und listAllLocales() tun werden, dann könnte vielleicht die erste Option ideal sein. Oder Sie könnten sogar eine Kombination der beiden verwenden.

Wie für das Demeter-Gesetz, ist es mehr wie die Richtlinie von Demeter. Es ist in Ordnung, jede Regel zu brechen, solange Sie es bewusst tun, verstehen, warum Sie es tun, und die Konsequenzen, falls vorhanden, zu verstehen. Zum Beispiel, wenn die Verletzung des Gesetzes führt zu mehr wartbaren und lesbaren Code, aber Sie immer noch eine hochrangige Trennung von Bedenken in Ihrer Anwendung zu bewahren, ist es in der Regel in Ordnung. Ich würde mir also keine Sorgen darüber machen, ob eine der beiden Optionen das Gesetz bricht oder nicht.

+0

Hallo Jeff, danke für deine Antwort.Über die Duplizierung verwende ich referenzielle Integritätsbedingungen (InnoDB), so dass der languageCode und der regionCode Fremdschlüssel mit Einschränkungen sind. Ich mag diesen Stil, da es das Abrufen des Viele-zu-Viele-Rowsets erleichtert, ohne dass Sie der Locale-Tabelle beitreten müssen. Aber ich möchte in der Lage sein, von Sites abgekoppelte Locales hinzuzufügen. Hoffe, das macht Sinn. Wie auch immer, ich sehe was du sagst. Ich denke, Sie haben mich davon überzeugt, beide Möglichkeiten zu nutzen, da ich beide Szenarios verwenden werde (zuerst im Frontend, dann im Admin-Backend). Danke für deinen Beitrag. –

+0

Danke nochmal Jeff. Ich werde meinen Kuchen essen und es auch essen. :) –