Лучшая практика разделения логики приложения

В моем приложении я выделил следующие уровни логики приложения:

  1. Утилиты
  2. Абстракция приложения
  3. Простая/обычная реализация абстракции приложения (#2)
  4. Конкретная реализация приложения (дополнительные функции и классы для добавления № 3, чтобы соответствовать нашим окончательным целям приложения)
  5. абстрактная архитектура приложения mvc (абстракция для логики приложения mvc)
  6. конкретное приложение mvc

Описание этих уровней:

  1. Утилиты, библиотеки и прочее... (не имеет зависимости, может использоваться каким-либо конкретным классом приложений)
  2. Абстрактные классы приложения. Определяет очень абстрактные классы приложений (не имеет зависимости)
  3. Конкретные классы абстрактного приложения. Определяет обычно конкретные классы абстрактного приложения (имеют зависимость с логическим уровнем #2)
  4. Конкретные (окончательные) приложения. Определяет наши классы finally для конкретной модели приложения (имеют зависимость с логическим уровнем #3 и #2)
  5. абстрактная архитектура MVC приложения. Определяет абстракцию для нашего конкретного приложения MVC (не имеет зависимости)

  6. конкретная MVC-архитектура приложения: конкретный контроллер, представления, модели. Конкретный рабочий процесс приложения (MVC: представления как представления, модели как прокси, контроллер для связи обоих)

    • Models are simple Proxies that work with level #4 (dependence with #5 and #4)
    • Контроллер и представление не знают о том, какие классы использует модель (не имеет зависимости ни от одного уровня, кроме #5).
    • Модель обменивается данными с представлением, используя «объекты значений» (определенные в логике № 5)

Пример приложения для игры в автомобили:

  1. EngineUtils, TrackUtils и так далее

  2. ICar, ITrack, IEngine, ITrackFactory, IEngineFactory и так далее

  3. Car, Track, SimpleEngine, AdvancedEngine, EngineFactory и так далее (реализовать интерфейсы #2)

  4. HondaCar, FordCar, BMWCar, TorontoTrack, TokyoTrack, DushanbeTrack, KualaLumpurTrack, TrackFactory, SuperEngine, ExtendedEngineFactory и так далее

  5. ITrackProxy, ICarProxy, CarVo, TrackVo, TrackListVo, CarListVo и так далее

  6. GameController, TrackView, CarView, CarProxy, TrackProxy и так далее. Обмен данными по модели ‹-> представление: CarVo, TrackVo, TrackListVo, CarListVo и т.д.

Что вы думаете об этих уровнях? И если все в порядке, я думаю, как разделить все эти уровни в проекте? (по пространствам имен или по библиотекам). Если пространства имен, то у меня проблема с именованием этих пространств имен...


oop model-view-controller abstraction business-logic
person pleerock    schedule 13.11.2012    source источник
comment
Думаю, в данном случае было бы полезно знать, с каким языком вы работаете.   -  person net.uk.sweet    schedule 13.11.2012
comment
Я использую java. но имеет ли это значение? Вопрос больше зависит от архитектуры, чем от платформы или языка.   -  person pleerock    schedule 14.11.2012

Ответы (1)


arrow_upward
1
arrow_downward

Это очень похоже на то, как я сейчас управляю проектами (на любой платформе/языке).

Я предпочитаю помещать утилиты в отдельный проект/библиотеку и присваивать им универсальное пространство имен, например com.yourdomain.Core или что-то в этом роде. Затем эта библиотека будет создана для использования в любом приложении, даже за пределами Cars Games.

Я думаю, что вы можете поместить № 2 (рефераты) и № 3 (общие конкретные) в ту же папку/пакет/пространство имен/проект, что и абстрактная библиотека приложений (№ 5). Я думаю, что никакой другой проект, кроме проектов Cars Games, не нуждается в ссылках на рефераты и общие конкретные примеры, так что вы можете поместить их в библиотеку абстрактных приложений. В противном случае вы можете хранить № 2 и № 3 вместе в одной библиотеке и ссылаться на нее из абстрактной библиотеки приложений.

В конкретном приложении я бы создал определенные классы (№ 4), справочные утилиты и абстрактную библиотеку приложений (которая будет содержать абстракты (включая интерфейсы) и общие сведения).

person Mickael Caruso    schedule 03.12.2012
comment
Я рад, что кто-то написал ответ. И я рад, что у кого-то есть похожая структура проекта. Спасибо за ваш совет, я подумаю о них и посмотрю, что я могу улучшить в моей текущей структуре проекта. - person pleerock; 03.12.2012