Как вы организуете занятия на большом проекте? - PullRequest
1 голос
/ 03 апреля 2009

В нашем приложении имеется масса функций, которые очень конкретно можно описать как модуль. Обычно есть своего рода диалоговое окно настройки, затем, когда пользователь нажимает «ОК», он настраивает процесс для запуска и запускает этот процесс. Иногда они активируются, и пользователь открывает новое диалоговое окно и некоторое время работает над ним, выполняя множество действий, которые вносят изменения в базовую базу данных.

Обычно у меня несколько стандартных классов

ConfigPanel.cs
ConfigPanelData.cs
ProcessRunner.cs
ApiWrapper.cs (for calling the process from somewhere else)

Если бы у меня был более сквозной модуль, это могло бы быть WorkerPanel.cs WorkerData.cs SetupOptions.cs (состояние панели сохраняется между запусками) Lib / WhateverBackendStuffINeedToSupportModule ApiWrapper

Прямо сейчас есть папки для каждой:

UI/Panels/
    Module1Panel.cs
    Module2Panel.cs
UI/PanelData/
    Module1PanelData.cs
    Module2PanelData.cs
UI/PanelManagers
    Module1PanelManager.cs
    Module2PanelManager.cs
Core/Module1/
    Module1.cs
    Module1Helpers.cs
Core/Module2/
    Module2.cs
    Module2Helpers.cs

Как видите, все действительно разложено. С более чем 50 модулями эти папки на самом деле не организованы. Даже разбивая их по подсистемам, они все еще беспорядок. Не будет ли плохим дизайном просто собрать все вместе, чтобы все разделялось по функции, а не по типу класса?

Module1/
    Module1Panel.cs
    Module1PanelData.cs
    Module1PanelManager.cs
    Module1PanelLib.cs
    Module1PanelWrapper.cs
Module2/
    Module2Panel.cs
    Module2PanelData.cs
    Module2PanelManager.cs
    Module2PanelLib.cs
    Module2PanelWrapper.cs

Как вы организуете свои занятия и каковы преимущества / недостатки?

1 Ответ

0 голосов
/ 03 апреля 2009

Будет ли плохой дизайн просто поставить все вместе, так что все разделены по функции, а не тип класса?

Нет общего правила, оно зависит от ситуации, ваших личных предпочтений и изменений в вашем коде. Однако я бы предложил сделать следующее:

  • Сохраняйте как можно больше общего кода в суперклассах, чтобы исключить любую избыточность. Может быть, тогда некоторые из подклассов даже не понадобятся.
  • Я не уверен, что вы подразумеваете под "модулями", но я бы порекомендовал разделить вещи, используя пространства имен + подкаталоги в одном проекте, а не с помощью отдельных сборок. Используйте сборки только для целей разделения развертывания и тому подобного.
  • Те упомянутые вами "вспомогательные" классы звучат немного вонючо. Они могут быть нарушением принципов ОО. Перейдите по этой ссылке для получения дополнительной информации: http://blogs.msdn.com/nickmalik/archive/2005/09/06/461404.aspx. Может быть, вы сможете реорганизовать код, сократить потребность в таких классах И одновременно получить преимущество от более чистого дизайна ОО?
...