Variante B (Entscheidung Richard): Modul-UI entfernt statt in Zwischenprojekte ausgelagert. Avalonia ist plattformuebergreifend, die neuen Ansichten kommen spaeter direkt in die Modul-Projekte zurueck - kein Zwischenschritt, keine Wegwerfarbeit. - 23 WinForms-Dateien aus den 4 Modulen entfernt (Spezifikation steht in docs/UI-SPEZIFIKATION-WinForms.md, Originalcode im Tag winforms-final). - RegisterUi ist jetzt je Modul ein dokumentierter No-Op: View-ID, Titel, Gruppe, Order und der Tab-Aufbau stehen als XML-Doku drin, damit der Avalonia-Nachbau die stabilen IDs und die Struktur uebernimmt. - Alle 4 Modulprojekte + Testprojekt: net8.0 statt net8.0-windows, UseWindowsForms raus. - P4 vorgezogen (war durch den Testprojekt-Wechsel faellig): PDFsharp-MigraDoc-GDI -> PDFsharp-MigraDoc (Core-Build). Der Core-Build findet keine Systemschriften, daher neu Logic/PdfFontResolver.cs: durchsucht die Schriftverzeichnisse des OS nach Segoe UI/DejaVu/Liberation/Noto/Arial/FreeSans. Keine Schriftdateien im Repo noetig; fehlt auf Linux alles, kommt eine klare Meldung mit apt-Hinweis statt eines kryptischen Renderer-Fehlers. Verifiziert: Core, alle 4 Module und das Testprojekt publishen fuer linux-x64, und zwar ohne ein einziges Windows-spezifisches Paket in den deps.json. 442 Tests gruen (inkl. PDF-Rendering) auf net8.0. Windows-App laeuft weiter mit den Core-Fenstern. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
80 lines
4.6 KiB
C#
80 lines
4.6 KiB
C#
using System.Threading;
|
||
using System.Threading.Tasks;
|
||
using Microsoft.EntityFrameworkCore;
|
||
using Microsoft.Extensions.Configuration;
|
||
using Microsoft.Extensions.DependencyInjection;
|
||
using PolyTrader.Core.Configuration;
|
||
using PolyTrader.Core.Modularity;
|
||
using PolyTrader.Modules.ResolutionFarming.Persistence;
|
||
using PolyTrader.Modules.ResolutionFarming.Persistence.Ef;
|
||
|
||
namespace PolyTrader.Modules.ResolutionFarming
|
||
{
|
||
/// <summary>
|
||
/// Strategiemodul „ResolutionFarming": kauft systematisch unterbewertete Favoriten (~0.90–0.98)
|
||
/// in bald auflösenden Märkten, hält bis zur Resolution und löst ein (Favorite-Longshot-Reversal).
|
||
/// Erstes neues Strategiemodul über Copytrading hinaus – geringster Infrastrukturbedarf.
|
||
///
|
||
/// Aufbau (inkrementell): geldkritische Entscheidungslogik liegt pur und unit-getestet in
|
||
/// <c>Logic/</c> (FarmingRiskEngine, FarmingScanner, FarmingFillModel); Persistenz, Scanner-Job,
|
||
/// Execution und UI folgen in eigenen Slices. Live-CLOB/On-Chain-Redeem sind Zielland-Arbeit.
|
||
/// </summary>
|
||
public class ResolutionFarmingModule : IPolyTraderModule
|
||
{
|
||
public string Name => "ResolutionFarming";
|
||
public string DbPrefix => "rf_";
|
||
|
||
public void RegisterServices(IServiceCollection services, IConfiguration configuration)
|
||
{
|
||
// Modul-Persistenz: EF Core / Pomelo / MySQL (thread-safer DbContextFactory), eigene rf_-Tabellen.
|
||
var conn = configuration["Database:MySqlConnectionString"] ?? string.Empty;
|
||
services.AddDbContextFactory<ResolutionFarmingDbContext>(o => o.UseMySql(conn, DatabaseServerVersion.Value));
|
||
|
||
services.AddSingleton<IRfSettingsRepository, EfRfSettingsRepository>();
|
||
services.AddSingleton<IRfCandidateRepository, EfRfCandidateRepository>();
|
||
services.AddSingleton<IRfPositionRepository, EfRfPositionRepository>();
|
||
services.AddSingleton<IRfClosedTradeRepository, EfRfClosedTradeRepository>();
|
||
|
||
// Read-only-Scanner (Phase RF-1). Marktquelle vorerst NullFarmingMarketSource: das Modul
|
||
// läuft ohne Live-Gamma/CLOB-Anbindung (die im Zielland registriert wird) und produziert
|
||
// dann korrekt keine Kandidaten.
|
||
services.AddSingleton<Services.IFarmingMarketSource, Services.NullFarmingMarketSource>();
|
||
services.AddSingleton<Services.MarketScannerService>();
|
||
services.AddHostedService(sp => sp.GetRequiredService<Services.MarketScannerService>());
|
||
|
||
// Demo-Execution + Resolution-Monitor (Phase RF-2). Marktauflösungs-Quelle vorerst Null
|
||
// (nichts löst auf), bis die Live-Data-API im Zielland verdrahtet ist. Live-Order-Execution
|
||
// und On-Chain-Redeem sind ebenfalls Zielland-Arbeit.
|
||
services.AddSingleton<Services.IMarketResolutionSource, Services.NullMarketResolutionSource>();
|
||
services.AddSingleton<Services.FarmingExecutionService>();
|
||
services.AddHostedService(sp => sp.GetRequiredService<Services.FarmingExecutionService>());
|
||
services.AddSingleton<Services.FarmingResolutionMonitorService>();
|
||
services.AddHostedService(sp => sp.GetRequiredService<Services.FarmingResolutionMonitorService>());
|
||
|
||
// Live-Marktquelle, Live-Execution, On-Chain-Auto-Redeem und Kalibrierung folgen (Zielland).
|
||
}
|
||
|
||
/// <summary>
|
||
/// Aktuell ohne Ansicht: Die WinForms-UI wurde mit der Linux-Portierung entfernt, die
|
||
/// Avalonia-Ansicht folgt (Stufe L3/L4). Die Fachlogik dieses Moduls laeuft davon
|
||
/// unabhaengig weiter – die Shell zeigt schlicht kein Fenster fuer das Modul an.
|
||
///
|
||
/// <para><b>Beim Nachbau zu erhalten</b> (Spezifikation: docs/UI-SPEZIFIKATION-WinForms.md,
|
||
/// Originalcode: Git-Tag <c>winforms-final</c>):</para>
|
||
/// <list type="bullet">
|
||
/// <item>View-ID <c>resolutionfarming.main</c> (stabil – Launcher-Button und Symbol haengen daran)</item>
|
||
/// <item>Titel <c>ResolutionFarming</c>, Gruppe <c>ResolutionFarming</c>, Order <c>200</c></item>
|
||
/// <item>Ein Fenster fuers ganze Modul: ResolutionFarmingMainForm mit Tabs: Kandidaten / Positionen / Historie+Statistik / Settings</item>
|
||
/// </list>
|
||
/// </summary>
|
||
public void RegisterUi(IModuleUiHost host, IServiceProvider services)
|
||
{
|
||
// Bewusst leer, bis die Avalonia-Ansicht steht (siehe Doku oben).
|
||
}
|
||
|
||
public Task StartAsync(CancellationToken cancellationToken) => Task.CompletedTask;
|
||
|
||
public Task StopAsync(CancellationToken cancellationToken) => Task.CompletedTask;
|
||
}
|
||
}
|