Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, Аноним, Вы писали:

А>>Что касается разделения классов, то здесь я просто предлагал использовать разделение на GUI и BL. Сейчас диалоги работают напрямую с объектами, т.е. передаем диалогу ссылку на некий объект FilterEntity и диалог сам его изменяет, заполняет. Наверное, само по себе это уже не очень хорошо.
ГВ>Само по себе это ни хорошо, ни плохо.
Подумал, согласен.

А>>Плюс, вышеназванная проблема именования — просто так теперь класс этого объекта не переименовать, т.к. все предыдущие проекты завязаны на старом названии.
ГВ>Значит, старые проекты тоже должны обновиться. Или "заморозиться".
Тоже вариант, но пока до заморозки рановато. Приходилось вносить незначительные изменения во все проекты. Есть шансы что еще придется.

А>>Я бы сделал так: создал бы класс FilterEntityGui, который выставляет наружу только самые необходимые свойства для конкретного диалога FilterDialog. И работает данный конкретный диалог с этим классом. А все остальные пользователи этого диалога используют выходные данные по своему усмотрению.
ГВ>Пока что маловато обоснований для прослойки. Зачем она? Если только для того, чтобы ограничить интерфейс Filter — то неправильно ставишь задачу. Прослойку имеет смысл делать только ради того, чтобы проще было решать какие-то задачи. Какие?

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

Да, в первую очередь хотелось бы ограничить интерфейс Filter GUI. Как было в примере, в 3 разных проектах используется один и тот же диалог, но из-за того, что в нем используется класс сущности для извлечения данных, неудобно эту саму сущность изменять.

Попробую описать свою проблему конкретным примером

Структура проектов такая:
1. PluginProject1 (enum FilterTypes1)
2. PluginProject2 (enum FilterTypes2)
3. PluginCoreProject3 (BaseFilter, KeywordsFilterDialog, ListFilterDialog)

В PluginCoreProject3 есть классы фильтра BaseFilter и диалогов KeywordsFilterDialog, ListFilterDialog.
У фильтра BaseFilter есть поле Type — типа int.

public class BaseFilter
{
  private int type;
  public int Type {get; set;}

  ...
}

public class KeywordsFilterDialog : Form
{
  public KeywordsFilterDialog(BaseFilter filter)
  {
    ...
  }
}

Проекты PluginProject1 и PluginProject2 используют BaseFilter, но Type трактуются в каждом по-своему. Для этого заведены enum'ы FilterTypes1 и FilterTypes2. В коде же используются преобразования типа:

  FilterTypes1 ft = (FilterTypes1) myFilter.Type;

и, соответственно, обратые преобразования:

  BaseFilter filter = filters.GetFilterByType( (int) FilterTypes1.Books);

Такие конструкции неудобны, когда дальше в логике приходится интенсивно использовать Filter.

Была идея сделать BaseFilter generic'ом, которому передавался бы свой enum в каждом проекте, но тут я уперся в диалоги. Диалоги в своих конструкторах обязательно принимают BaseFilter как один из аргументов. Неудобно конструктору GuiControl'а передавать generic тип. Использовать дизайнер форм становится сложнее.

Основной аргумент, против таких идей — не стоит вообще так заморачиваться для наших небольших проектов

А>>Просто интересно, сталкивался ли кто с таким? Может, зря я паникую
ГВ>Да нет, вроде не зря. В именах, ИМХО, путаница получается.

ГВ>Попробуйте для начала перепроектировать структуру классов, только выкиньте эти дурацкие приписки Entity — любой объект и так Entity. Получится, как минимум, Filter и Condition. Сразу вылезает интересное наблюдение: Filter включает в себя Condition и какое-то поведение по отношению к "фильтруемому" объекту. По крайней мере, с точки зрения семантики человеческого языка.
Я тоже противник приписки Entity, но поскольку моему коллеге они удобны, я не настаиваю категорически.