[Expand]General Information
[Expand]WinForms Controls
[Expand]ASP.NET Controls and MVC Extensions
[Expand]ASP.NET Bootstrap Controls
[Expand]ASP.NET Core Bootstrap Controls
[Collapse]WPF Controls
 [Expand]What's Installed
 [Expand]Common Concepts
 [Expand]MVVM Framework
 [Expand]Controls and Libraries
 [Collapse]Scaffolding Wizard
   Getting Started
    System Requirements
    Common Application Architecture
    Functionality Overview
    View Types
    Structure of Classes in a Scaffolded Application
    Unit of Work Policy
  [Expand]Data Access Layer
   UI Generation
  Redistribution and Deployment
  Get More Help
 [Expand]API Reference
[Expand]Xamarin Controls
[Expand]Windows 10 App Controls
[Expand]Office File API
[Expand]Report and Dashboard Server
[Expand]eXpressApp Framework
[Expand]eXpress Persistent Objects
[Expand]CodeRush Classic
[Expand]Cross-Platform Core Libraries
[Expand]Tools and Utilities
 End-User Documentation
View this topic on docs.devexpress.com (Learn more)

Structure of Classes in a Scaffolded Application

This topic describes the basic structure of generated application Class diagrams and code snippets taken from the https://www.devexpress.com/example=T322553 example. This example is based on the Data Access Layer generated with the Entity Framework Code First. You can download this example or instead create it yourself by completing the following tutorial: UI Generation.

This topic consists of the following sections.

Expanded Data Model Layer

The data structure used in the T322553 example is shown below.

Two crucial concepts in the Data Model are UnitOfWork and Repository.

UnitOfWork is a transaction. It provides access to Repositories and tracks any changes made to those Repositories.

Repository is a collection of entities of a particular type and is always owned by the UnitOfWork that created it. Any changes made to a Repository can be committed to the database using the associated UnitOfWork.

The UnitOfWork concept is represented by the IUnitOfWork interface. Each scaffolded application contains a IUnitOfWork descendant that contains repositories specific to the application. In the example, it is the IDepartmentContextUnitOfWork interface.

There are two implementations of the specialized IUnitOfWork interface in a generated application. One is used at run-time and the other-at design-time. In the example, these implementations are the DepartmentContextUnitOfWork and DepartmentContextDesignTimeUnitOfWork classes.

The Repository concept is represented by the IRepository and IReadOnlyRepository interfaces. No concrete implementations of these interfaces are generated. Instead, the two generated IUnitOfWork implementations create instances of the IRepository or IReadOnlyRepository interfaces.

To acquire an IUnitOfWork instance, an instance of the IUnitOfWorkFactory interface is needed first. Such an instance can be obtained with the UnitOfWorkSource.GetUnitOfWorkFactory() method. The UnitOfWorkSource class is generated by the Scaffolding Wizard and creates an instance of either the run-time implementation of the IUnitOfWork or design-time implementation.

Expanded View Model Layer

All view models generated with the Scaffolding Wizard are POCO classes.

There are two types of view models generated by the Scaffolding Wizard:

  • collection view models that allow you to operate with collections of entities of a specific type;
  • single object view models that allow you to operate with a single entity of a specific type.

Below is the collection view models hierarchy.

ReadOnlyCollectionViewModelBase is the base class for view models exposing a read-only collection of entities of a given type using the Entities property. The SelectedItem property can be used to synchronize selected items with the view (the GridControl.SelectedItem property in the generated application). The FilterExpression property can be used to filter loaded data. The Refresh method recreates the underlying unit of work and reloads data. Since CollectionViewModelBase is a POCO view model, an instance of this class will also expose the RefreshCommand property that can be used as a binding source in views.

ReadOnlyCollectionViewModel is an empty partial class that inherits ReadOnlyCollectionViewModelBase and provides the extension point to add custom properties, commands and override methods without modifying the auto-generated code.

CollectionViewModelBase adds Delete, Edit, and Save methods to the ReadOnlyCollectionViewModelBase. These methods will be exposed as commands at runtime (the DeleteCommand, the EditCommand, and the SaveCommand).

CollectionViewModel is an empty partial class that inherits the CollectionViewModelBase class.

The CourseCollectionViewModel, DepartmentCollectionViewModel and EmployeeCollectionViewModel classes represent view models used to operate with collections of specific domain objects. Since all logic is implemented in the base classes, these view models are quite simple.

The single object view models hierarchy is shown below.

SingleObjectViewModelBase is the base class exposing a single entity (the Entity property) and CRUD operations against this entity. The Close, Delete, Save methods will be exposed as commands at runtime (CloseCommand, EditCommand, SaveCommand).

SingleObjectViewModel is an empty partial class that inherits SingleObjectViewModelBase.

CourseViewModel, DepartmentViewModel and EmployeeViewModel represent view models used to operate with specific domain objects. CourseViewModel and EmployeeViewModel expose the LookUpDepartments property that provides a look-up collection of all departments that is the items source for the Grid Lookup Editor used to edit the Employee.Department and Course.Department properties in the UI. DepartmentViewModel exposes two nested collection view models (DepartmentCoursesLookUp and DepartmentEmployeesLookUp) used to represent the Department's detail collections (Department.Courses, Department.Employees) in the UI. The code of these view models is below.

DepartmentContextViewModel is located in the root of the project. It provides an entry point view model of the generated application and uses IDocumentManagerService to create collection views.

Expanded View Layer

View Layer consists of collection views (CourseCollectionView, DepartmentCollectionView and EmployeeCollectionView) bound to collection view models and single object views (CourseView, DepartmentView, EmployeeView) bound to single object view models.

POCO view models are created using ViewModelSourceExtension in XAML.

View model commands are represented in the UI by the RibbonControl that automatically merges with the ribbon in DepartmentContextView at runtime.

The entity detail editing form is represented by the LayoutControl.

The collection view contains a GridControl that allows you to group, sort, filter and search through the data.

Note that the GridControl has the EventToCommand behavior attached. It executes the CollectionViewModel.EditCommand when the user double clicks a data row.

The DepartmentContextView is located in the root of the project and provides an entry point view that contains a RibbonControl, a Tabbed MDI Container and a Navigation Pane forming the Microsoft Office-inspired UI of the application. See the Functionality Overview topic for more details.

Is this topic helpful?​​​​​​​