# General structure of our c-entron<span>.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](https://nhibernate.info/) 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:

```csharp
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<T> 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:
```csharp
public interface IAccountContractsLogic
{
    Task<Result<IList<AccountContractDTO>>> GetAccountContracts(GetAccountContractsFilter filter);
    Task<Result<AccountContractDTO>> SaveAccountContract(AccountContractDTO accountContract);
    // ... other methods
}
```

#### 2. BL Implementation (Direct Database Access)
```csharp
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)
```csharp
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`:

```csharp
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](../guides/ui/localization.md).

- 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.