Common Interfaces

Note

This information is a little outdated, although it's roughly accurate as an overview of the architecture.

Composition Roots

Instagile currently targets three app models:

The.IServices

This is for console applications and is also a common subset of the other app models; business logic code written against The.IServices is cross-platform and can run in any environment. Many features are or should be available at this level - data access, security, logging, settings, import and export... however, to get a fully functioning IServices may require extra initialisation work. This is due to async I/O and login considerations which the other three models, being fully-integrated platforms, can solve automatically in an environment-specific way.

The.WPF.IServices : The.IServices

Intended for desktop GUI applications, either on net4x or netcoreapp3+. Provides a single login session with a current Principal that's used for all contexts by default.

The.Web.IServices : The.IServices

Intended for web applications based on ASP.NET Core. Provides a request-scoped instance (or tab-scoped when using Blazor components), with transient Entity Contexts for use within a request/page. Includes services to support either a pure-client model (i.e. WebAssembly), or, with an extra package, backend-tier features.

Injected Services

These things aren't actually injected when using WPF or Core (but watch this space - we might start providing optional MEDI service descriptors). Still, they're the units of lifetime scope that you can get out of the framework.

IPrincipal

Your security context, as acquired from the environment in a platform-specific way. May represent a logged in user, or a guest/logged-out state, or an authentication failure. Can be given to an IServices (or some sort of internal partial IServices..?) to create a Context.

Lifetime: scoped to some sort of user session, which may be tied to an OS login, an HTTP request, or a long-running remote session.

IEntityContext

Unit of work for entity data. Builds up and can then save or discard changes, similar to a transaction. Requires a Principal and can provides a Services.

Lifetime: from a long-running gui 'screen' to a single piece of business logic.

IServices (or a subtype thereof)

Provides access to many useful things. Can create Principals... sometimes. This may be a matter of splitting up the interface into a full Services which has ambient authentication (and therefore the ability to create principals) and a lower-level partial Services which can, given a potentially asynchronously-acquired Principal, use it to instantiate a full Services.

Lifetime: varies - a console app or unit tests will have as many as it likes, WPF will have a single quasi-global, Web will have one per http request and Blazor will have one per websocket user or per WASM module (corresponding in either case to an open tab).