Skip to main content

Xomega Solution Structure

After you create a solution using the Xomega solution wizard, you will see your selected projects in the Solution Explorer.

For example, if you specify SolutionName as the initial project name, pick all components from the solution wizard, and keep the default naming conventions for the projects, then you will see the following projects created in your new solution.

Solution structure

Let's review the default structure of each project in the Xomega solution.

Model projects​

In the middle of the solution, between client and services projects, you'll find a couple of special projects for modeling the application.

SolutionName.Model​

Xomega model project combines .xom files that store Xomega model elements and configurations, as well as various generators that you can run on your model. We discuss the structure of the model project in the next chapter.

SolutionName.Model.Diagrams​

This project exists solely for the purpose of creating diagrams of your entity data model. The Entity Data Model (EDM) is generated from the Xomega domain model, so that you could use the entities you define to create visual diagrams that help you to better understand the structure of your domain model, which, in turn, helps you build your applications faster and more efficient.

Shared project​

Xomega solution will contain one C# project that is shared between services and the client projects, as follows.

SolutionName.Services.Common​

This project should have minimal dependencies and contains any code or resources that are shared between the service layer and the clients.

By convention, different types of shared artifacts are grouped into their own folders, as follows.

  • ServiceContracts contains interfaces for the services and structures for the corresponding data contracts (i.e., DTOs).
  • Enumerations contains constants for static enumerations and their items/properties, as well as for attributes of dynamic enumerations. It also contains XML data for static enumerations in the enumerations.xres file, which is loaded into the Xomega Framework's lookup cache.
  • CacheLoaders contains lookup cache loaders for loading dynamic or contextual lookup data from the service operations so that it could be used for lookup and validation both on the client and server sides. It also contains a convenient method for registering those with the DI container.
note

Most of those classes are auto-generated from the Xomega model, but you can also add any custom code that needs to be shared between client-side and server-side logic, such as helper classes for security checks, etc.

Services projects​

The following projects are used to implement business services for your solution and to expose them to the client(s).

SolutionName.Services.Entities​

This project contains Entity Framework's domain entities for your solution with the configuration of the DbContext, and provides an implementation of the business services defined in the .Services.Common project using those entities.

info

This project has no dependencies on any server-side frameworks, such as ASP.NET Core, so it could be (re)used from any server-side or client-side frameworks.

By convention, the entities and the services are grouped into the following folders, which can be further broken down by module.

  • Entities contains the Entity Framework entities and the DbContext configuration.
  • Services contains an implementation of the business services.
note

These folders may include both classes generated from the Xomega model and any custom extensions or subclasses with overridden implementations.

The project also includes a DbContextValidation class that has some helper validation methods that are used by the service implementations.

SolutionName.Services.Rest​

This project allows exposing business services implemented in the .Services.Entities project via REST API using ASP.NET Core.

Initially, it will have a Program file that contains the startup and configuration code, as well as an AuthController class for password-based authentication.

Once you define RESTful operations in the Xomega model, it will also have generated controllers for those services and operations.

note

You can also add your own classes to customize the behavior of the generated controllers or provide additional Web API logic.

SolutionName.Services.Wcf​

This project allows exposing business services implemented in the .Services.Entities project via legacy WCF framework hosted using ASP.NET.

By default, it has a startup class WcfAppInit with initialization logic and a set of classes under the Sts folder that help you implement a Security Token Service that is needed to set up security for the WCF services.

Otherwise, it will generate .svc service host files for the Xomega business services defined in the model.

Client projects​

Based on your configuration, the Xomega solution will have a number of projects that are used on the client side of your app. Below you will find detailed descriptions of these projects for various types of clients.

SolutionName.Client.Common​

This project contains common C# presentation logic for your solution that is shared between various C#-based clients.

info

This project should have no dependencies on any specific UI framework, such as Blazor, to allow sharing it with other C# clients and support an easy migration of your app to any future UI technologies, such as MAUI.

By convention, the common client classes are grouped by their types into the following folders.

  • DataObjects contains Xomega Framework data objects that are bound to UI views.
  • ServiceClients contains proxy services for calling business services via REST.
  • ViewModels contains Xomega Framework view models that include data objects and provide additional platform-agnostic presentation logic for the UI views, such as navigation.
note

These folders may include both classes generated from the Xomega model and any custom extensions or subclasses with overridden implementations.

In addition to the classes, this project also contains the following common resource files for the UI views.

  • Labels.resx contains resources generated from the Xomega model.
  • Resources.resx contains any common custom resources that may override the generated ones or provide additional resources, such as custom validation messages.

SolutionName.Client.Blazor.Common​

This project contains Blazor views, components, and other resources that can be shared between Blazor Server and Blazor WebAssembly projects.

info

The project should have no dependencies on ASP.NET Core or the specific flavor of the Blazor implementation to remain sharable between different types of Blazor clients.

The project contains the following folders and files.

  • Components folder contains shared Blazor components, such as the MainLayout and LoginDisplay components.
  • Views folder contains generated and custom Blazor views and a menu structure, including a home page.
  • wwwroot folder contains shared resources such as CSS files, javascript, and images.
  • App.razor file defines the main application component.

SolutionName.Client.Blazor.Wasm​

This project contains WebAssembly startup and setup code for a Blazor WebAssembly client that uses application views and components from the .Client.Blazor.Common project. It also includes WebAssembly-specific implementation classes for authentication and authorization.

Standalone WebAssembly projects that are not hosted by the main Blazor app will have a main index.html page for the app under the wwwroot folder.

SolutionName.Client.Blazor​

This is the main Blazor project that contains ASP.NET Core startup and setup code for a Blazor Server client and hosted REST API, as appropriate. It uses application views and components from the .Client.Blazor.Common project, and references the .Client.Blazor.Wasm WebAssembly project when the latter is hosted by this Blazor app.

SolutionName.Client.Maui​

This project contains the code for a MAUI desktop/mobile client for your application. The root folder contains the main program MauiProgram with DI-enabled application initialization code, App.xaml for the main application and the MainPage.xaml with the BlazorWebView that shows application views and components from the .Client.Blazor.Common project.

The MAUI project also contains the following sub-folders.

  • wwwroot folder contains static Blazor resources, such as index.html for the HostPage of the BlazorWebView.
  • Components folder contains additional Blazor components specific to the MAUI project, such as SignOut.razor.
  • Platforms folder contains code and resources for each individual platform: Android, iOS, MacCatalyst, Tizen and Windows.
  • Resources folder contains resources that are shared between all platforms: AppIcon, Fonts, Images, Raw and Splash.

SolutionName.Client.Wpf​

This project contains the code for a WPF desktop client for your application. The root folder contains the main application in the App.xaml files, the main window in the MainView.xaml files, and other application files in sub-folders, as follows.

  • App_Start folder contains DI-enabled application initialization code.
  • Controls folder contains common WPF controls that are used in the application views, e.g., for displaying errors.
  • Views folder contains generated XAML views with the code-behind that use view models and bind to data objects from the .Client.Common project.

SolutionName.Client.Web​

This project contains the code for the legacy ASP.NET WebForms web client that targets .NET Framework. The root folder contains the main application master page in the Site.Master file and other application files in sub-folders, as follows.

  • App_Start folder contains the DI-enabled application initialization code for Owin.
  • Content folder contains web application resources, such as CSS and images.
  • Controls folder contains common WebForms user controls that are used in the web views, e.g., for displaying errors.
  • Scripts folder contains javascript resources and libraries.
  • Views folder contains generated ASPX views with the code-behind that use view models and bind to data objects from the .Client.Common project.

SolutionName.Client.Spa​

This project contains a web client as a TypeScript-based Single Page Application (SPA). It uses business services exposed via REST API and is implemented with XomegaJS framework backed by the Knockout.js library, as well as with the Durandal framework.

warning

Because this client is implemented with TypeScript and HTML, it cannot reuse any of the shared common C# projects and therefore needs to re-implement all the presentation logic in TypeScript.

The root folder contains the main application initialization code and markup, as well as the following sub-folders.

  • App_Start contains the app startup and configuration code.
  • CacheLoaders contains XomegaJS lookup cache loaders for loading contextual lookup data from the service operations to be used for lookup and validation.
  • Content folder contains web application resources, such as CSS and images.
  • DataObjects contains XomegaJS data objects that are bound to UI views.
  • Enumerations contains TypeScript constants for static enumerations and their items/properties, as well as for attributes of dynamic enumerations.
  • ServiceContracts contains TypeScript data contracts (i.e., DTOs) and service methods that call the corresponding REST API.
  • Scripts folder contains javascript resources and libraries.
  • Views folder contains generated and custom views with HTML markup and TypeScript view models.
  • Widgets folder contains common components that are used in the views.