Masterarbeit/QuellCode/CentronERP/docs/getting-started/general-structure.md

General structure of our c-entron.NET for developers

Lets get this out of the way first: there are tons of places where this general structure does not apply, places that use more or less layers, places that use the wrong type of object and all other sorts of horrific code. You're welcome to fix this wherever you think it needs to be fixed, but atleast all new code should follow this structure.

layer	objectype	description
UI		the UI with which the horrifiyng User interacts
ViewModel	DTO/ViewModel	converting DTOs to ViewModels so they can be interacted with via Bindings or similar
ILogic/BLLogic/WSLogic	DTO	clientside interaction with the DB (BLLogic) or a remote webservice (WSLogic)
ICentronRestService/CentronRestService	DTO	the actual webservice methods that can be called from other apps
WebServiceBL	Entity/DTO	converting entities to DTOs
BL	Entity	interaction with NHibernate and the database itself
database		the horrifiyng land of the database

Client-Side Data Access (WPF UI)

The c-entron.NET WPF client uses a sophisticated data access pattern that supports both direct database access and web service communication through a unified interface system. If the naming guidelines are followed, the client will automatically register the ILogic with the corresponding BLLogic and WSLogic.

ClassContainer and ILogic Pattern

The client accesses data through the ClassContainer singleton using the ILogic interface pattern:

var result = await ClassContainer
    .Instance
    .WithInstance((IAccountContractsLogic logic) => logic.GetAccountContracts(filter))
    .ThrowIfError();

This pattern provides:

• Dependency injection through ClassContainer
• Unified interface for data access
• Error handling with Result pattern
• Async/await support for all operations

Dual Implementation Architecture

Every module MUST implement both data access methods:

1. ILogic Interface

Defines the contract for data operations:

public interface IAccountContractsLogic
{
    Task<Result<IList<AccountContractDTO>>> GetAccountContracts(GetAccountContractsFilter filter);
    Task<Result<AccountContractDTO>> SaveAccountContract(AccountContractDTO accountContract);
    // ... other methods
}

2. BL Implementation (Direct Database Access)

public class BLAccountContractsLogic : IAccountContractsLogic
{
    private readonly ConnectionInfo _connectionInfo;
    
    public Task<Result<IList<AccountContractDTO>>> GetAccountContracts(GetAccountContractsFilter filter)
    {
        return Task.Run(() =>
        {
            using (var session = new BLSession())
            {
                return session.GetBL<AccountContractWebServiceBL>()
                    .GetAccountContracts(this._connectionInfo.GetLoggedInUser(), filter);
            }
        });
    }
}

3. WS Implementation (Web Service Access)

public class WSAccountContractsLogic : IAccountContractsLogic
{
    private readonly ICentronWebServiceConnection _connection;
    
    public Task<Result<IList<AccountContractDTO>>> GetAccountContracts(GetAccountContractsFilter filter)
    {
        return this._connection.CallWebServiceMethodWithListResultAsync(f =>
            f.GetAccountContracts(this._connection.GetRequest(filter)));
    }
}

Connection Type Support

Modules declare supported connection types in their AppModuleController:

public CentronConnectionType[] SupportsConnectionTypes => new[]
{
    CentronConnectionType.CentronWebServices,  // Uses WSLogic implementation
    CentronConnectionType.SqlServer           // Uses BLLogic implementation
};

Benefits of This Architecture

• Flexibility: Same module works with direct database or web service
• Testability: Easy to mock ILogic interfaces for unit testing
• Consistency: Unified error handling and async patterns
• Maintainability: Clear separation of concerns
• Scalability: Can switch between local and remote data access

Implementation Guidelines

1. Always create the ILogic interface first defining all required operations
2. Implement both BL and WS classes - this is mandatory for all modules
3. Use consistent naming: I{Module}Logic, BL{Module}Logic, WS{Module}Logic
4. Return Result<T> from all logic methods for consistent error handling
5. Support async operations using Task<Result<T>> return types
6. Register in ClassContainer to enable dependency injection

Localization and UI Language Requirements

Because c-entron.NET is developed specifically for the German market, all user-facing content must adhere to the following guidelines:

German-First Language Policy

• All UI labels must be written in German
• All user messages must be written in German
• All documentation visible to end users must be in German
• Error messages displayed to users must be in German

Language Requirements

• All documentation visible to end users must be in German
• Error messages displayed to users must be in German
• Multi-language Support: The application supports both German (default) and English through separate resource files
  • German text is stored in base resource files (LocalizedStrings.resx)
  • English translations are stored in language-specific resource files (LocalizedStrings.en.resx)
  • When adding new localized strings, provide translations for both languages

Implementation Guidelines

For detailed information on implementing localization in the WPF client, including XAML usage, code-behind usage, and business logic integration, see the Localization Guide.

• Use German terminology consistent with the business domain
• Maintain consistent capitalization and formatting according to German language rules
• For technical terms without direct German equivalents, prefer the established German technical term over creating a new translation

File Encoding Requirements

To ensure consistent character representation and prevent encoding-related issues, the following encoding rules must be followed for all source files:

Required Encoding

• All C# source files (*.cs) must use UTF-8 with BOM encoding
• All XAML files (*.xaml) must use UTF-8 with BOM encoding

Benefits of UTF-8 with BOM

• Ensures proper handling of special characters and international text
• Prevents encoding-related merge conflicts
• Maintains consistent line endings across development environments
• Enables correct display of all characters in the IDE

IDE Configuration

In Visual Studio:

1. Go to Tools > Options > Text Editor > [Language] > File Extension
2. Set "Encoding" to "Unicode (UTF-8 with signature) - Codepage 65001"

When Creating New Files

When creating new files, always ensure the encoding is set to UTF-8 with BOM. This applies to all new source code files added to the project.