• разработка Flex рабочее Вообще, последнее время ненавижу, когда классы, даже в концепции MVC, называют BullShitController, MailController. Ну контроллер, круто. А что конкретно он контролирует? Весь Mail? Не жмет?

    С учетом того, что сам по себе MVC даже не паттерн, а просто набор общих соображений с разными вариантами реализации, такие общие названия можно давать всему, что угодно. В любом случае, трудно по названию ожидать от класса чего-то конкретного. Мне, если честно, даже открывать такие классы страшно. Боюсь разочарований.

    И, кстати, чем даже стремные фреймворки типа Cairngorm, лучше доморощенных реализаций, так это тем, что в них можно более-менее точно предугадать, чего ждать от класса, названного по шаблону.
    ♡ recommended by @develar, @O01eg, @wackum

Replies (26)

  • @Constantiner, я думаю, что правильней будет не "более-менее точно", а "чуть более точно". ибо если не дано понять MVC, то и никакой другой паттерн понять не дано. ну, синглтон, разве что.
  • @prof, Хм. Что значит не дано понять? Каждый понимает. В меру того, как можно понять общие рекомендации. И это и плохо.

    Вообще, все к тому, чтобы просто называть менее абстрактно и более конкретно. И да, не делать мегаклассов, а делить их. Тогда и название будет более точным.
  • @Constantiner, ну так механистический же подход. "вот тут в примере вот это положили в контроллер, а это во вью, а модель — это набор VO. блин, а у нас еще вот такая хрень есть... куда ее-то положить? в примере-то нету... ну, давайте в команду положим". ну вот так и ложат все то, что за рамками примеров, куда ни попадя.
    справедливости ради, надо заметить, что деление всего на небольшие классы приводит к адову количеству маленьких классов, в которых разобраться тоже не просто...
  • @Constantiner, ну а packege-ы можно хоть именовать model, view ?
  • @gAmUssA, нужно, я считаю
  • @prof, кстати, классы я именую с использованием суффиксов View и PM (presentation model). т.е. у меня есть BullShitView и BullShitPM
  • @gAmUssA, нельзя. riapriority.com
  • @gAmUssA, Ну это как раз даже лучше.
  • @develar, Ну мнение Гахова не является законом. Он отразил лишь один взгляд. А есть система разделения зависимостей и пакетов по слоям. Мне, например, она больше нравится.
  • @Constantiner, Гахов, возможно, прав. Но не до конца. Он не учел, что слои и домены — они не так строго перпендикулярны, как в его вышеупомянутой статье. Т.е. совсем не обязательно, что в каждом домене есть классы предметной области и классы UI, и наоборот — слой можно дробить на несколько доменов.
    Меня сейчас больше притягивает к структуре, в которой разбиение на верхнем уровне идет по слоям (модель, гуй, логика приложения, etc), а внутри слоя, если классов много — деление по субдоменам.
  • @prof, в маленькой проекте разделение на "packege-ы можно хоть именовать model, view" c натяжкой еще можно оправдать, ну а в большом удобнее дробить именно по "логике и функциональности" — даром нужно создавать еще какие-то пакеты model и view? Если хочется разграничить view и модель на уровне некой файловой структуры, то делать это нужно именно новым модулем (subproject в мавене, то бишь multimodule project), а не некими суррогатными пакетами.
  • @develar, вот именно по логике и функциональности если делить, то и получается, что сначала нужно делить на модель и гуй (это ну совсем-совсем разная функциональность), а потом, внутри них — как-то еще. А как именно делить — на модули, пакеты или еще как-то — это уже дело десятое. имхо
  • @prof, модуль и GUI это не разная функциональность. Функциональность это то, что реализует программа — форма заказа товара, к примеру. А разделение на модель и GUI это уже не логика/функциональность, а детали реализации. И смысла разносить это по разным пакетам нет никакого.
  • @develar, ну вот смотри: есть предметная область — обработка заказов на товары. мы и объекты предметной области, и гуй запихали в один пакет. Потом поняли, что с ростом мобильного интернета нам не отвертеться от создания отдельного гуя для мобильных. А потом к нам пришли и сказали: вы клевые ребята, нам нравится, как вы работаете, давайте вы нам сделаете еще один гуй для менеджеров, обрабатывающих заказы. По-прежнему пихать все классы в тот же пакет?
    Я считаю, что правильно все классы модели реализовать в пакете .model, а классы гуев — в .ui.web, .ui.mobile, .ui.managers, и, возможно, вынести общие гуевые классы в *.ui.common. А бить ли все это дело на модули — это совершенно перпендикулярная задача, это уже не логическое, это техническое.
  • @prof, Вот. Именно!
  • @develar, Ключевые слова — слои приложения.
  • @Constantiner, Нет. Потому что вряд ли дело ограничится UI и потребуется создавать некие классы типа новой карты mate и чего-то подобного. Вы что же, будете иметь ui.mobile и model.mobile? По мне, так удобнее будет создать в пакете order пакет mobile (можно еще вынести в модуль другой).
  • @prof, Именно. Модули лишь способ организации кода и зависимостей. Наиболее распространенное разделение на модули как рас и идет по слоям.
  • @develar, Нет. Я за подход @prof.
  • @Constantiner, Стал часто опечатываться :(
  • @Constantiner, меня тут беспокоит вот что — есть пакет mobile, если у тебя вдруг для него будет не только UI, но и еще что-то (предположим, ты модель размещаешь в пакете model), то получится, что будет два пакета mobile, лежащих в разных родительских пакетах — order.ui.mobile order.model.mobile
  • @develar, о! ты карты mate тоже в модель кладешь?! в таком случае мне остается только прекратить дискуссию.
  • @prof, карты mate как пример, я вообще не разделяю по пакетам суррогатным model/ui, а кладу все по логическим order. order.mobile
  • @develar, Боженька покарает за два пакета? Или в чем проблема?
  • @develar, да не должно быть у тебя разных model. model — она на то и model, чтоб не зависеть от типа клиента, поставленной задачи и т.п. От задачи зависит лишь степень проработки модели.
    ну и на #1136447/23 здесь отвечу: как сказал Костя, это не какие-то там суррогатные пакеты, это пакеты слоев приложения (даже больше — системы, если приложений несколько). По-хорошему, хорошо построенную модель и нужно выносить в отдельный модуль, ибо она будет core для всех приложений.
  • @Constantiner, в том, что в приложении логически сколько mobile? 1. А пакета почему-то два :) Вот с ui, как суррогатом, это нормально.