NOVINKA - Online rekvalifikační kurz Python programátor. Oblíbená a studenty ověřená rekvalifikace - nyní i online.
Hledáme nové posily do ITnetwork týmu. Podívej se na volné pozice a přidej se do nejagilnější firmy na trhu - Více informací.

Diskuze: WinForm - předávání dat mezi formuláři

V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.

Jak se ti líbí článek?
Před uložením hodnocení, popiš prosím autorovi, co je špatněZnaků 0 z 50-500
Jak se ti kurz líbí?
Tvé hodnocení kurzuZnaků 0 z 50-500
Aktivity
Avatar
Jan Kejval
Člen
Avatar
Jan Kejval:11.6.2020 13:09

Ahoj,

po prostudování článků tady na síti týkající se C# a dalších dostupných zdrojů jsem se jal vše ověřit praxí, takže píšu menší winform aplikaci.
Nicméně bych se chtěl zeptat zkušenějších členů na doporučení ve dvou problematikách.

  1. Jak správně předávat data mezi formuláři.

Primárně mi jde o kolekce, které využívají ovládací prvky v primárním formuláři, ale i následně formuláře volané z primárního.
Z DB hlediska je neefektivní v novém formuláři data do kolekcí opět načítat, když už je mám v hlavním formuláři. Takže mi vychází, buď kolekce předat přímo v konstruktoru formuláře, popřípadě při větším množství kolekcí předat jen interface obsahující metody vracející dané kolekce z volajícího formuláře.

  1. Zda je dobrý nápad používat custom FormFactory třídu obsahující metody pro vytváření instancí formulářů a její instanci (rozhraní) přidat do IoC containeru, kterým řeším (zkouším řešit) závislosti.

Přijde mi to jako ideální řešení pro případ vnořených formulářů, kdy konečný form, který je několikátý v řadě, vyžaduje manažera(y) pro zápis dat do DB. Standardně bych musel závislost předat přes konstruktory formů, které dané managery vůbec nepotřebují, popřípadě znovu vytvářet instance managerů v konkrétním formu.
Kdežto při použití factorky bude Interface manažera jako parametr v jejím konstruktoru, tudíž bude závislost předána containerem a instance daných formulářů se budou volat pomocí metod factorky.
Daná metoda bude obsahovat parametry pro data, ale manažeři budou předaný třídou.

Příklad metody:

public Form GetFormManageFunctionModel(string formName, int functionId, IObjectRequester caller)
        {
            var _myForm = new FormManageFunction(this, _modelManager, _functionManager, caller, functionId);
            _myForm.Name = formName;
            return _myForm;
        }

Následně z formů volám jen danou metodu a nemusím řešit zavilost pro _modelManager a _functionManager

Pokud jsem úplně mimo, prosím nakopnout s přiložením odkazu, kde si počtu.

Díky za přečtení a případné odpovědi.

 
Odpovědět
11.6.2020 13:09
Avatar
zelvicek
Člen
Avatar
zelvicek:12.6.2020 8:18

Winforms (nebo jakékoliv jiné UI) je jen xicht zobrazující cosik. Měl bys mít "engine" obsahující různé služby (načítání a ukládání dat, posílání notifikací, ...). UI už pak bude "jen" pracovat s engine-m. UI nesmí být hlavní částí - maximálně může spouštět/inici­alizovat engine.
Představ si, že bys měl několik UI (WF, mobile native i web).
Nezapomínejme na starou dobrou 3-vrstvou architekturu.

Toliko teorie. Pro malou apku to samozřejmě moc smyslu nemá a DB connection klidně narvi do konstrukturu formu.

 
Nahoru Odpovědět
12.6.2020 8:18
Avatar
zelvicek
Člen
Avatar
zelvicek:12.6.2020 8:23

Hmm, už nemůžu editovat.

Výhodné je mít engine napsaný tak, aby bylo možné jej hostovat samostatně i v rámci UI (což zjednodušuje použití pro jednodušší desktop apky, ale nenutí přepisovat celé jádro, když manažer přijde s cool nápadem).

 
Nahoru Odpovědět
12.6.2020 8:23
Avatar
Jan Kejval
Člen
Avatar
Jan Kejval:12.6.2020 17:35

Ahoj,
díky za reakci.
Třívrstvou architekturu se snažím držet.

Mám Datovou vrstvu s repository třídami , kde jsou metody pro CRUD a BULK operace.
Metody pro práci s DB jsou dále segregované pomocí Interfaců do logických celků.
Pro conection string používám factory třídu, která aktuálně čte connection string z config souboru.

V logické vrstvě mám manažery, kteří přes interface z Data vrstvy, obsluhují repository a připravují/zpra­covávají data z/do UI vrstvy.
připojují se na externí rest rozhraní a tak. (zkouším si naimplementovat kde co, ať vím , jak se to dělá a chová :))

UI nemá žádnou vyšší dívčí. Stará se jen o prezentaci dat a volání služeb (mail ...).

Protože jsem od povahy línej, tak mě opisování kódu (předávání konstruktorem), nebo vytváření instancí pořád dokola nebaví, tak jsem se koukal na IoC kontainer a ten mi funguje, jen prostě nevím, jestli je to správně a nejde to proti nějakému principu.

Díky

 
Nahoru Odpovědět
12.6.2020 17:35
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 4 zpráv z 4.