Каковы лучшие характеристики фреймворка уровня данных для приложений WPF / MVVM?

Я создаю платформу WPF / MVVM, которая генерирует код для классов модели.

Я планирую иметь для каждой таблицы базы данных / веб-службы (например, «Клиенты») два класса моделей:

  • особый класс модели (например, "Клиент")
  • и класс модели множественного числа (например, "Клиенты")

Класс единственной модели имеет все свои свойства (FirstName, LastName и т. Д.), А также все методы, которые имеют смысл для отдельного экземпляра, например Сохранить (), Удалить (), Рассчитать зарплату () и т. Д.

Класс множественной модели имеет коллекцию единичных объектов модели, а также те же методы, так как вы хотели бы также работать с группой единичных объектов, например Save (), Delete (), CalculateSalary (), а также определенные методы, такие как Sort (), и методы, которые упростили задачу для определенных групп, например LoadAllGoldCustomers () или даже LoadWithSql (строка sql) и т. Д.

Я делал подобный фреймворк раньше (PHP), и он упростил написание и понимание такого кода:

Customers customers = new Customers("all");
customers.CalculateSalary();

Пара унаследованных классов (Item и Items) взяли большую часть кода из отдельных классов единственного и множественного числа для каждой таблицы базы данных, что сделало среду очень чистой для программирования.

Однако я редко видел, чтобы другие приложения делали это разделение классов модели на единственное / множественное число. Вместо этого почти всегда есть только один класс для каждой таблицы базы данных, например Customer, и у этого класса есть необходимые методы множественного числа, например GetCustomers (строка sql) и т. Д.

Я только что заметил в WPF Model-View-ViewModel Toolkit 0.1 Пошаговое руководство, в них вы должны сделать две модели своих "Моделей", каталог двух классов:

  • Customer.cs (только поля)
  • CustomersDataSource.cs (один метод List Load ())

Это похоже на аналогичную концепцию, только класс "множественного числа" называется источником данных.

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

  • ясность и простота программирования с помощью ViewModel, отсюда четкое разделение классов модели единственного и множественного числа, вам просто нужно создать экземпляр класса единственного или множественного числа и вызвать для него метод, и у вас есть свои данные .
  • хорошо вписывается в шаблон MVVM (что, как я понимаю, означает максимально простое, просто иметь свойства и методы, которые может вызывать ViewModel, но не реализовывать никаких специфичных для WPF функций, таких как INotifyProperityChanged)
  • хочу, чтобы мой слой данных располагался над любым источником данных, поэтому, если я использую LINQ-to-SQL, я все равно вызываю свои собственные классы моделей, и если я хочу переключиться на сохранение в Oracle, я пишу более низкие данные слой адаптера для моих классов, чтобы с ним взаимодействовать.
  • Воспользуйтесь преимуществами LINQ наилучшим образом

Я был бы признателен за отзывы от тех, кто разработал слои данных для фреймворков, особенно с использованием WPF / MVVM / Composite Application Library, и какие характеристики, которые вы нашли, работали лучше всего, или если вы работали с другими фреймворками, такими как CSLA, Subsonic и т. Д. Кроме того, любой опыт или идеи о том, как LINQ изменяет / упрощает построение структуры уровня данных. Спасибо.


person Edward Tanguay    schedule 14.05.2009    source источник


Ответы (1)


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

Во-первых, попытка перенести фреймворк или какие-либо характеристики этого фреймворка с одного языка на другой кажется попыткой воткнуть квадратный стержень в круглое отверстие. Хотя я не сомневаюсь, что функции (например, клиентов и клиентов) могут быть перенесены, я определенно могу возразить, что их не следует переносить. Придерживаясь примера customer.CalculateSalary, вы могли бы использовать .NET и создать метод расширения для IEnumerable, который делал бы то же самое, устраняя необходимость в этом классе Customers. Я понимаю, что у вас могут быть и другие функции, но это всего лишь пример. Другой пример - использование LINQ для сортировки IEnumerable.

Во-вторых, я лично обнаружил, что наличие методов сохранения (например, Save, Delete и т. Д.) Внутри объекта не очень хорошо работает в большой системе, особенно при работе с WCF. Похоже, что в этих сценариях лучше использовать какой-либо тип репозитория позже, что, похоже, также хорошо подойдет для вашей точки перехода на Oracle в середине разработки.

Я также хочу полностью не согласиться с вами по поводу того, как хорошо вписаться в MVVM. Для меня модель представления - это клей между моделью и представлением. Не только вероятно, что модель представления должна знать о представлении (следовательно, о конкретных функциях WPF), но и желает, чтобы она знала об этом. ICommand - это важный интерфейс, о котором должна знать модель представления, и это одна из сборок WPF-y (WindowsBase, PresentationCore, PresentationFramework, не могу вспомнить, какая). Кроме того, INotifyPropertyChanged также имеет решающее значение для привязки данных и должен быть реализован во всех моделях представления и не имеет ничего общего с WPF (я думаю, происходит из System.ComponentModel?).

Это мои два цента. Опять же, очень сложно объяснить это в кратком ответе на ваш вопрос. Я бы порекомендовал использовать этот паттерн на некоторое время, прежде чем создавать для него каркас. Удачи!

person poindexter12    schedule 18.08.2009
comment
+1, потому что вы указали, что методы сохранения не работают должным образом внутри объекта и что вместо них можно использовать PI (игнорирующие постоянство) PONO (простые старые сетевые объекты (также POCO, простые старые объекты CLR)). - person tobsen; 21.08.2009