Как мне разрешить эту терминологическую путаницу при рефакторинге существующего кода для использования шаблона MVVM? - PullRequest
Новая
       18

Как мне разрешить эту терминологическую путаницу при рефакторинге существующего кода для использования шаблона MVVM?

2 голосов
/ 01 февраля 2010

Я борюсь с терминологическим конфликтом и не могу найти хорошее решение. Может быть, у кого-то еще была эта проблема.

Я перестраиваю существующее приложение WinForms для использования WPF. Я буду использовать шаблон MVVM в моем новом приложении. Мое старое приложение широко использует ADO; в частности, у меня есть Row объекты, которые обертывают DataRow объекты. И когда я хочу определить, какие столбцы в строке могут отображаться в определенном контексте в пользовательском интерфейсе, определение находится в объекте RowView.

Концептуально, «представление» является подходящим термином для этого - один базовый DataRow может иметь несколько Row объектов, каждый из которых использует RowView объект для определения своих подмножеств своих столбцов, прав доступа и т. Д., Много как было бы в базе данных SQL. Объекты ColumnView, которые в коллекции RowView ColumnViews содержат метаинформацию о представлении каждого столбца в этом конкретном представлении.

Это все удар по схеме MVVM с мокрым стуком. В MVVM «представление» означает что-то другое: это означает представление объекта пользовательским интерфейсом. * * * * * * Мое приложение * не является представлением, поскольку MVVM обеспокоен. Для MVVM в действительности не существует RowView объекта как такового, но есть базовый RowViewModel, который поддерживает логику взаимодействия между пользовательским интерфейсом и конкретным Row объектом, и базовый ColumnView объект для каждого из столбцы строки.

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

Наивный ответ, когда это происходит, - «пространства имен», но, хотя использование пространств имен для устранения неоднозначности этих терминов, безусловно, сработает технически, У меня есть серьезные сомнения, что это поможет разгадать путаницу, с которой сталкивается новый разработчик, когда сталкивается этот код один бит.

Другая возможность - изменить имя объекта Row на другое. Например, я мог бы использовать «строку» и «столбец» в модели, а также «запись» и «поле» в представлении и модели представления. Таким образом, я мог бы составить Record из Row и RowView и Field из каждого значения столбца и ColumnView. Тогда я мог бы иметь объекты RecordViewModel и FieldViewModel, которые были бы открыты для WPF, и разработчик пользовательского интерфейса никогда бы не узнал о существовании таких объектов, как объекты RowView и ColumnView. Но этот вид тоже воняет.

Кто-нибудь еще сталкивался с такой проблемой при перестройке программного обеспечения для использования MVVM? Какого черта ты сделал?

1 Ответ

1 голос
/ 01 февраля 2010

Я бы предпочел добавить в этих случаях что-то вроде обратной венгерской нотации.

  • * ModelView или * DataView для моделей (Пример: ExpenseModelView или ExpenseDataView )
  • * UIView для самих представлений (Пример: ExpenseUIView )

Лично я использую пространства имен и небольшую коллекцию соглашений. Я знаю, где находятся мои модели и как они используются, потому что я использую их последовательно во всем приложении, а также в своих виртуальных машинах и представлениях. Я могу отличить View, ViewModel или Model от того, как и где они используются или на которые они ссылаются, и я думаю, вы также найдете то, что делаете.

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

...