Granularization моделей?

Question

Granularization моделей?

Я разрабатываю CMS в основном на основе компонентов Платформы Зенда. Некоторые таблицы базы данных для этого CMS как сопровождаются:

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

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

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

У меня есть названная модель Site который состоит, среди других, следующих методов:

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

Я нахожусь отчасти на заборе о том, как granularized я должен определить модели:

Одна опция состояла бы в том, чтобы возвратиться SiteLocale объекты/модели (другими словами, представление Таблицы базы данных) от listLocales() метод, где они SiteLocale объекты содержат следующие методы:

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()

Другая опция состояла бы в том, чтобы просто создать следующие методы в Site модель, и быть сделанным с ним:

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

Что делает Вы чувствуете, что правильный путь состоит в том, чтобы пойти? И почему?

Кроме того, был бы, первая опция (или возможно даже обе опции) нарушают Закон Demeter?

РЕДАКТИРОВАНИЕ (22 января)
Хотя мне нравится ответ Jeff, я все еще открыт для новых/других перспектив.

5

models law-of-demeter granularity

задан Community 23 May 2017 в 12:26

1 ответ

Другие вопросы по тегам:

models law-of-demeter granularity

Похожие вопросы:

score 3 · Accepted Answer

Во-первых, относительно таблиц базы данных: вы, вероятно, могут дополнительно нормализовать базу данных. Существует дублирование между таблицами Locale и Site_Locale. Конечно, я не вижу большой картины здесь, так что может быть что-то за то, как вы это сделали.

Честно говоря, любой вариант в порядке. Я бы выбрал дизайн, который делает ваш код более читаемым и поддерживаемым. Например, если вы выбрали первый вариант, вы бы в конечном итоге с такими петлями по всему этому месту?

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

Если так, то я избежу его и пойду со вторым вариантом и в конечном итоге с:

do_something(site.getDefaultLocale())

это гораздо более понятно с быстрым взглядом. Может быть, даже улучшит производительность вашего сайта.

Однако, если вы думаете, что вы будете делать много работы, которые используют списки Sitelocales в будущем, но вы точно не знаете, что вы собираетесь делать помимо getDefaultLocale () , listactiveLocales () , и ListallLocales () , то, возможно, первый вариант может быть идеальным. Или вы можете даже использовать комбинацию двух.

Что касается закона Демитера, это больше похоже на руководство Демитера. Это нормально, чтобы сломать любое правило, пока вы это делаете сознательно, понимаю, почему вы это делаете, и понимаете последствия, если таковые имеются. Например, если нарушение закона приводит к более ремонсимому и читаемому коду, но вы все еще сохраняете разделение высокого уровня опасений в вашем приложении, это вообще нормально. Поэтому я бы не беспокоился о том, нарушает ли или нет варианта.