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

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

6 голосов
/ 14 мая 2009

Я создаю платформу 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, и какие характеристики оказались наиболее эффективными или если вы работали с другими фреймворками, такими как CSLA, Subsonic и т. Д. Также, любой опыт или идеи о том, как LINQ меняет / упрощает построение структуры слоя данных. Спасибо.

1 Ответ

3 голосов
/ 18 августа 2009

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

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

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

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

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

...