DOCSEARCHbyAlgolia
Submit Docs

CSLA .NET Documentation

repository·main·Indexed 23 days ago

https://github.com/marimerllc/csla

A framework for creating reusable, object-oriented business logic layers. CSLA .NET provides a five-layer architecture to decouple business rules from user interfaces and data storage, featuring tools for data validation, persistence, and state management. Key features in CSLA 10 include source-generated properties via [CslaImplementProperties], attribute-based data portal methods ([Create], [Fetch], [Insert], [Update], [Delete]), and dependency injection integration using IDataPortalFactory and the [Inject] attribute.

Tokens
40.3K
Snippets
95
Records
234
Agent score
80%

What's inside CSLA .NET

  1. Overview of CSLA Templates

    main
    The CSLA Templates package provides pre-defined templates for creating CSLA projects and individual items within a CSLA architecture. These templates are designed to help developers quickly scaffold the necessary project structures and components required for a standard CSLA implementation.

  2. Overview of CSLA .NET

    main
    CSLA .NET is a software development framework designed to help developers build reusable, maintainable, and object-oriented business layers for applications. It aims to reduce the cost of building and maintaining complex business logic by providing a structured framework for managing business rules, data access, and object state.

  3. What is CSLA .NET?

    main

    CSLA .NET is a framework designed to provide a dedicated home for business logic, elevating it to the same level of importance as the UI and data access layers. Instead of using 'anemic' data containers (objects that only hold data), CSLA encourages an object-oriented approach where models are designed around behavior and business scenarios.

    Key capabilities include:

    • Cross-platform compatibility: Runs anywhere .NET code can run.
    • Rules Engine: A flexible, reusable engine for implementing validation, business, algorithmic, and authorization rules.
    • Abstracted Data Binding: Provides standardized data binding that works across Blazor, ASP.NET, MAUI, Windows Forms, WPF, and other platforms.
    • Abstracted Persistence: Supports both local and remote data access (via HTTP) while abstracting the low-level plumbing.
    • Data Access Neutrality: Works with any technology, including ADO.NET, Entity Framework, Dapper, and more, to access various data sources like SQL Server, Oracle, or web services.

  4. Explore CSLA .NET Sample Categories

    main

    The CSLA .NET samples are organized into three distinct categories to help developers learn different aspects of the framework:

    1. ProjectTracker: A comprehensive reference application used in the Using CSLA books. It features a common business layer with multiple UI projects, a data portal appserver, and both mock and SQL data access layers. Note: This sample may not always reflect the absolute latest CSLA features due to its alignment with book publication cycles.
    2. Example Samples: Small, focused, and simple examples (e.g., BlazorExample, RazorPagesExample) designed to show basic CSLA usage across different UI platforms. These typically use a 1-tier deployment (local data portal) to minimize setup complexity and focus on how UI technologies interact with a common business layer.
    3. Other Samples: Specialized samples demonstrating specific CSLA .NET features such as Business Rules, Data Portal capabilities, Web API integration, and platform-specific UI implementations (Windows Forms, WPF).

  5. Choose the correct CSLA version for your project

    main

    CSLA is available in several versions depending on your target framework and stability requirements:

    • CSLA 10: The latest development version (found in the main branch) which supports .NET 10.
    • CSLA 8 and 9: Current stable versions available in the v8.x and v9.x branches.
    • CSLA 7 and 6: Older versions available in v7.x and v6.x branches. Warning: These versions have known issues; it is recommended to use version 8 or higher.
    • Legacy Versions: Support and documentation exist for CSLA 5, CSLA 4, and CSLA .NET 3.8 for maintaining older systems.

  6. WPF Support in CSLA .NET

    main

    CSLA .NET provides extensive support for WPF through standard data binding and specialized productivity controls and components located in the Csla.Wpf namespace.

    Starting with CSLA 4, the primary collection and list base classes inherit from ObservableCollection<T> to ensure full compatibility with WPF's binding requirements, while legacy support for Windows Forms is maintained via renamed BindingList<T> base classes.

  7. New Features in CSLA 10

    main

    CSLA 10 introduces several key enhancements for modern .NET development:

    • Full Nullable Reference Type (NRT) support: The entire codebase supports NRT.
    • OpenTelemetry instrumentation: Built-in support for the data portal to enable observability.
    • Enhanced rules engine: Includes improved async exception handling.
    • Improved Metastate Performance: Uses binary serialization for metastate.
    • Custom Serialization: Provides the IMobileObjectMetastate interface for implementing custom serializers.

  8. Dependency Injection in CSLA 6 and later

    main

    Starting with CSLA 6, the library embraces Dependency Injection. All applications must configure an IServiceCollection and IServiceProvider on startup.

    Key static types are now provided as DI services. Specifically, the data portal types are now injected as:

    • IDataPortal<T>
    • IChildDataPortal<T>
    • IDataPortalFactory
    • IChildDataPortalFactory

    This change affects how you interact with ApplicationContext and the data portal.

  9. Understand Name-Based Data Portal Operation Dispatch

    main

    CSLA uses name-based dispatch to optimize Data Portal operations. Instead of relying on reflection or complex pattern matching on criteria types, the client computes a deterministic operation name based on the method's parameter types and sends it via the wire protocol. The server then uses this name for direct, $O(1)$ method dispatch.

    Naming Convention

    The operation name is constructed using the following rules:

    • No criteria: {OperationType}
    • With criteria: {OperationType}__{Type1}_{Type2} (only criteria parameters contribute to the name; [Inject] parameters are ignored).
    • Type Names: Uses Type.Name or MetadataName (e.g., Int32, String).
    • Generic Types: Replace the backtick with an underscore followed by the type arguments (e.g., List<int> becomes List_1_Int32).
    • Arrays: Uses the element type followed by Array (e.g., int[] becomes Int32Array).

  10. Understand the CSLA .NET Five-Layer Architecture

    main

    CSLA .NET is designed around a five-layer architecture to create a reusable business logic layer. This separation of concerns allows you to decouple your business rules from your user interface and your data storage.

    The five layers are:

    1. Interface layer: The human or API interface (e.g., a Console app, Web API, or UI).
    2. Interface control layer: Manages the interaction between the interface and the business layer.
    3. Business layer: Contains the business domain objects and logic.
    4. Data access layer (DAL): Handles the communication with data sources.
    5. Data storage layer: The actual persistence mechanism (e.g., SQL Server, an in-memory collection, or a file).

  11. Understand the Data Portal Dispatch Order

    main

    When a Data Portal operation is received, the server attempts to resolve the operation using the following priority order:

    1. Named Dispatch: Attempts to use IDataPortalOperationNamedMapping via the OperationName provided in the request.
    2. Criteria-based Dispatch: Falls back to IDataPortalOperationMapping (pattern matching on criteria types).
    3. Reflection: The final fallback using traditional reflection-based dispatch.

  12. Control rule execution with `RuleContextModes`

    main

    A new RuleContextModes enum has been added to provide granular control over when rules execute. The RuleContext.ExecuteContext property now includes the following flags:

    • Any: Rule executes in any context.
    • CheckRules: Rule executes during CheckRules calls.
    • CheckObjectRules: Rule executes during CheckObjectRules calls.
    • PropertyChanged: Rule executes when the property changes.
    • AsAffectedProperty: Rule executes as an affected property.