Project structure of a solution

A Lagoon application solution is organized into specialized projects. The demo solution Apps\Demo\Demo.sln illustrates this organization with the projects Demo.Client, Demo.Server, Demo.Model, Demo.Shared, Demo.Services, and Demo.Batch, alongside the framework modules.

Repository solutions

The repository distinguishes solutions by work area:

Solution	Role
Modules\Modules.sln	Lagoon framework libraries.
Apps\<App>\<App>.sln	Solution for an application or a demo application.

Projects of an application

Project	Role
Client	Blazor WebAssembly client web application.
Server	Server web application: hosting, server pages, controllers, authentication.
Batch	Console application for batch commands.
Services	Server-side shared services.
Model	Database abstraction with Entity Framework Core.
Shared	Shared data: constants, enumerations, roles, policies, and ViewModels.

Client

The Client project contains the Blazor WebAssembly interface: pages, components, client-side HTTP services, static resources, and the UI translation dictionary.

In Apps\Demo\Client\Demo.Client.csproj, the project references in particular:

• Demo.Shared, for shared ViewModels, roles, policies, and constants;
• the Lagoon UI modules needed by the application, for example Lagoon.UI, Lagoon.UI.Custom, Lagoon.UI.GridView, or Lagoon.UI.Notifications.

The client entry point calls LagoonWebAssemblyApplication.RunAsync<Main>(args). The Main class inherits from LgCustomApplication and can configure global behaviors, root components, client services, and client-side policies.

Server

The Server project hosts the ASP.NET Core application, serves the Blazor WebAssembly application, exposes API controllers, and configures authentication.

In Apps\Demo\Server\Demo.Server.csproj, the project references:

• Demo.Client, to host the WebAssembly application;
• Demo.Services, to access server-side business logic;
• Lagoon.Server, for Lagoon server infrastructure.

The server entry point calls LagoonWebApplication.Run<Main>(args). The Main class inherits from LgAuthApplication<ApplicationDbContext, ApplicationUser> and configures, in particular, the DbContext, services, HTTP pipeline, authentication, authorizations, and database updates.

Model

The Model project contains the Entity Framework Core layer: ApplicationDbContext, entities, migrations, and seeders.

In Apps\Demo\Model\Demo.Model.csproj, the project references Demo.Shared, Lagoon.Model, and the EF Core packages used by the application. The demo context is defined in Model\Context\ApplicationDbContext.cs and inherits from LgApplicationDbContextGuid<ApplicationUser>.

EF Core migrations are placed under Model\Migrations\. The demo solution contains, for example, the migration 20230412074341_Init.cs and the generated snapshot ApplicationDbContextModelSnapshot.cs.

Shared

The Shared project contains elements consumed by several layers: ViewModels, constants, enumerations, roles, and policies.

In Apps\Demo\Shared\Demo.Shared.csproj, the project references Lagoon.Shared. It is used by Client and Model, which makes it possible to share contracts without depending on the server projects.

Services

The Services project contains the server-side business services. In the demo solution, Apps\Demo\Services\Demo.Services.csproj references Demo.Model and Lagoon.Services.

Application services are registered in a Services\Registry.cs class with a static RegisterServices(IServiceCollection services) method. The server and the batch applications call this registry from their configuration.

Batch

The Batch project is a console application. In Apps\Demo\Batch\Demo.Batch.csproj, it references Demo.Services and Lagoon.Console.

The batch entry point is a Main class that inherits from a Lagoon console application. Commands are declared with attributes such as [Subcommand(typeof(UpdateDbCommand))], and services are registered via Services.Registry.RegisterServices(services).

Dependencies between projects

The common pattern is as follows:

APP.Shared   ──►  APP.Model  ──►  APP.Services  ──►  APP.Server
                                                 └──►  APP.Batch
APP.Shared   ──►  APP.Client

This organization prevents the client from depending directly on the server or on the EF Core layer. Common contracts stay in Shared, persistence in Model, server-side business logic in Services, then the entry points in Server and Batch.

Related conventions

Namespaces

Namespaces follow the folder structure. For example, a service in Apps\Draft\Client\Services\ uses the namespace Draft.Client.Services.

Global usings

Each project has a _Usings.cs file to centralize global using directives. Imports used across an entire project should be placed there rather than repeated file by file.

Pages and components

Blazor pages and components always use two files:

MyPage.razor

@inherits LgPage

MyPage.razor.cs

namespace Demo.Client.Pages;

public partial class MyPage : LgPage
{
}

The .razor file contains the markup; the .razor.cs file contains the C# code of the partial class.

Dependency injection

Application services are grouped in a Services\Registry.cs file per layer. This registry exposes RegisterServices(IServiceCollection services) and typically uses direct registrations such as AddScoped<MyService>(), except when an abstraction is needed.

See also

• First project
• The Architecture page in this section presents the application overview.