Starší komentáře ke článku: Používáme návrhové vzory v .NET - Abstract Factory
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 14.2.2005 11:20:53
U "nas" v Jave se DCAL rika DAO a patri to mezi obecne J2EE vzory, ale to neni to o cem chci mluvit. Podle me ten navrh zanasi jednu nevyhodu pro klienty a to, ze jsou klienti primo svazani (musi ji explicitne volat) s tou factory. To ma napriklad nevyhodu pri testovani na urovni jednotlivych vrstev. Mnohem lepsi pristup, alespon z meho pohledu, je nastavit tu DALC komponentu z vnejsku. Tedy klient poskytne metody pro nastaveni toho co je potreba a "nekdo" z vnejsku tak ucini, rika se tomu obracena kontola a popisuje to enterprise navrhovy vzor Inversion of Control (IoC). Doporucuji nakouknout do kychyne Martina Fowlera a jeho clanku Inversion of Control Containers and the Dependency Injection pattern viz http://www.martinfowler.com/articles/injection.html
Datum vložení: 14.2.2005 11:30:54
Ano, souhlasim s Vami. Nicmene v uvodu clanku jsem psal ze clanek neresi stredni vrstvu,takze jakym zpusobem bude factory pouzivana zde neni reseno. Pro ukazku jsem pouzil nejjednodussi a nejnazornejsi moznost,kdy si klienti sami volaji factory a vytvari DALC. IMHO vsak pouziti teto tovarny i ve Vami navrhovanem scenari nic nebrani,pouze tovarnu nebude pouzivat klient, ale ten kdo je zodpovedny za nastaveni teto DALC komponenty klientovi z vnejsku.
Datum vložení: 15.2.2005 14:28:19
Jistě dáte zapravdu mému názoru, že problematika ukládání vnitřního stavu objektů není dosud v prostředí .NET konzistentně a uspokojivě řešena. Na jednu stranu zde máme množinu tříd pro přístup k datům ADO.NET a data-binding polí ve formulářích WinForms a WebForms, ale žádné integrované řešení pro objektově-relační mapování. Jinými slovy, pokud vyvíjím nějakou obchodní aplikaci, tedy mám např. třídu např. Customer a potřebuji ukládat její data (tj. hodnoty instančních položek dané instance) do relační databáze, musím pro tento účel (a také každou další třídu) vytvářet podpůrný kód zabývající problémem spouštění SQL příkazů a načítání a ukládání dat z/do dané instance. U jednoduché aplikace čítající několik "obchodních" tříd to ještě jde (a sám jsem si to vyzkoušel), ale u středně velké vnitropodnikové aplikace a složitých datových schémat tento přístup vede do pekel... Microsoft tuto otázku zatím evidentně neřeší - první vlaštovkou se zdálo být vydání .NET Frameworku 2.0 a spolu s ním ObjectSpaces, nicméně společnost se nakonec rozhodla ObjectSpaces integrovat až do nových Windows "Longhorn", u kterých mám osobně značné pochybnosti, kdy vlastně vyjdou na trh... Již delší dobu, cca 2 roky, se touto problematikou intenzivně zabývám. Pro své vlastní aplikace jsem vyvinul knihovnu zajišťující persistenci objektových dat v relační databázi, přičemž knihovna využívá deklarativního způsobu určení požadovaného (resp. cílového) relačního schématu. Takto persistované třídy nejsou nutně funkčně ani hierarchicky závislé na třídách této knihovny. Plánuji o tomto přístupu napsat vlastní článek, nicméně mám relativně málo času. Zajímalo by mne, zda o tuto problematiku máte zájem, příp. zda se tomuto tématu někdo z vás také věnuje, či věnoval, příp. s jakými výsledky?
Datum vložení: 15.2.2005 14:42:04
Osobne clanky i diskuzi na tema O/R mapovani v .NETu uvitam. MS tyto otazky jak pisete zatim opravdu neresi - otazka je, zda by to vubec delat mel. Vzoru pro persistenci dat je mnoho a je docela slozite ne-li dokonce nemozne vybrat jedno reseni ktere se hodi ve vsech scenarich a bude vyhovovat vsem.
Datum vložení: 15.2.2005 15:15:09
Osobně se domnívám, že by MS tuto problematiku řešit měl. Už jen z toho prostého důvodu, že konkurence (tj. Sun s Javou) tuto otázku řeší v rámci svého podpůrného frameworku. Pokud MS prezentuje platformu .NET jako "moderní" a "pokročilou", resp. "ideální pro vývoj podnikových aplikací", pak se domnívám, že pouhá podpora data-bindingu surových relačních dat na prvky formulářů toto zrovna nenaznačuje. A je to škoda, když má člověk při práci s třídami ADO.NET pocit, že se jedná polotovar, který si pro "rozumnou objektově-orientovanou práci" s daty chtě-nechtě musí rozšířit, resp. dovyvinout. Viz problém s užíváním třídy DataSet společně s třídami XxxDataAdapter. MS zřejmě nechápe, že aktualizace řádků v tabulkách musí probíhat v určitém pořadí (kvůli relacím mezi nimi), protože pak by se nemohl spokojit s pouhou implementací metody Update() na úrovni adaptéru, ale musel by řešit pořadí, v jakém se budou změny (tj. řádkový "insert", "update", "delete") promítat do databáze. Sečteno a podtrženo, osobně nabývám dojmu, že místo opravdu dotaženého (i když třeba jen relačního, nikoli objektového) paradigmatu odpojenéno přístupu k datům máme k dispozici pouze jakýsi nedodělek, který potřebuje ještě spoustu dalšího úsilí, aby byl opravdu použitelný v praxi.
Datum vložení: 24.2.2005 7:43:25
Tim podpurnym frameworkem myslite Hibernate? Za projektem Hibernate stoji samotny Sun? Existuje podpurny framework nHibernate pro .NET Framework.
Datum vložení: 24.2.2005 7:59:48
Aaa, tak ne, vy asi myslite JDO :-)
Datum vložení: 24.2.2005 8:02:44
Tech "podpurnych frameworku" (at uz v podobe O/R mapperu nebo jen nastroju pro snazsi generovani kodu datove vrstvy) existuje i pro .NET cela rada - viz napriklad http://sharptoolbox.com/Category74089b0a-1105-4389-b1db-eedf27e20cfb.aspx nebo http://sharptoolbox.com/Categorybf4853b9-2a87-4d40-9987-8744c3a6a9d6.aspx. Jsou samozrejme ruzne kvality a maji ruzne vlastnosti, ale myslim ze i v .NETu si clovek ma z ceho vybirat. Proto jsem take v drivejsim prispevku psal ze nevim jestli by MS mel do frameworku neco takoveho vubec davat, IMHO dost tezko lze vytvorit neco co by vyhovovalo vetsine potreb. Mozna i proto byly ObjectSpaces odsunuty na pozdeji, kdo vi...
Datum vložení: 15.2.2005 15:07:27
Ano, máte pravdu, ten článek jste načal už skoro před devíti měsíci, že? ;-)
Datum vložení: 15.2.2005 15:49:01
Nene, článek jsem tehdy nenačal, pouze jsem e-mailem kontaktoval redakci a sdělil svůj záměr článek napsat. Bohužel s časem je stále potíž, jak je vidět na časovém rozpětí (mail jsem psal 26.7.2004, takže je to nikoliv děvět, ale sedm měsíců :-). Minimálně je posunem alespoň to, že jsem si našel čas napsat alespoň příspěvek do diskuse :-) Ne, vážně, obsažný a přínosný článek, kterým bych chtěl přispět svou troškou do pomyslného .NET mlýna však lze stěží napsat za 10 min, tedy jako obyčejný příspěvek v diskusi.
Datum vložení: 15.2.2005 17:16:02
Vždyť jsem nenapsal nic zlého, ne? Jsou články, které už jsou domluveny naprosto napevno více než dva roky a jejich termín se měsíc co měsíc odsunuje - a to ten Váš zdaleka nebyl ;-)
Datum vložení: 12.6.2005 16:26:32
jednou z předních výhod nastupujícího .net 2.0 má být právě nezávislost na dtb stroji, následující ukázka snad hovoří za vše: DbProviderFactory provider = DbProviderFactories.GetFactory ("System.Data.SqlClient"); DbConnection connection = provider.CreateConnection (); DbDataAdapter adapter = provider.CreateDataAdapter (); ...přičemž pak stačí změnit System.Data.SqlClient za System.Data.Oracle (snad jsem se trefil:) a běžíme na oraclu... paráda, ne? :)
Datum vložení: 7.7.2005 21:34:38
Moznost zameny data providera v nove verzi ADO.NET je fajn vec, ale u vetsiny aplikaci s timto IMHO nevystacite. Na vine jsou nejen rozdily v implementaci SQL jazyka v jednotlivych databazovych strojich a zasadni rozdily v pouzivani nestandardizovanych veci jako jsou ulozene procedury, nebo treba takova banalni vec jako jsou parametry (ruzne znaky pro uvozeni parametru, podpora pojmenovanych/pozicnich parametru apod.). Takze se bohuzel vetsinou stejne dostanete k tomu, ze pro kazdy DB stroj tvorite vlastni DALC tridy, protoze na Oracle se vec kterou pouzivate dela uplne jinak nez na MS SQL apod.
Datum vložení: 7.7.2005 15:42:58
Muzete mi prosim poradit, jak predat connection string do jednotlivych jiz konkretnich tovaren a kdy by bylo nejlepsi otevirat a pripadne zavirat spojeni s databazi a kdy si ho drzet. Diky za odpoved
Datum vložení: 7.7.2005 21:28:38
Predavani connection stringu zalezi dost na typu aplikace. Pokud je connection string staticky, tak se da ulozit do konfigurace aplikace a tovarnam se nemusi predavat, ale tyto si jej samy z konfigurace nacitaji. Pokud se connection string meni v aplikaci (napr. uzivatel vybira pri startu aplikace databazi se kterou chce pracovat apod.), tak se to da resit napr. nejakym konfiguracnim singletonem v datove vrstve, do ktereh se connection string za aplikace nastavi a konkretni tovarna si jej potom cte odsud. Co se tyka otevirani a drzeni spojeni, tak ve filozofii ADO.NET plati celkem jasna zasada - otevirat spojeni co nejpozdeji a zavirat co nejdriv. Drzeni otevreneho spojeni pokud jej nepotrebuji se nedoporucuje - zbytecne se drzi nepotrebne zdroje ktere mohou pri vice pracujicich uzivatelich pak chybet a snizuje se tim skalovatelnost aplikace.
Datum vložení: 8.7.2005 8:49:06
Neni poprve, co slysim nazor ADO.NET=ZAVIRAT SPOJENI. Je k tomu nekde nejaky rozsahlejsi vyklad. Predelavam Delphi do .NET2 a trochu se toho desim. Par veci ktere bych asi musel resit jinak. Odesilani udalosti ze serveru na klienta - bez spojeni tezko. Prubezne docitani informaci dle potreby - vytvoreni spojeni chvilku trva a na desktopove aplikaci je pul vteriny nekdy moc. Udelal jsem si static databazi a mam ji celou dobu otevrenou. Hledam mozne problemy, abych pri vice klientech nebyl nemile prekvapen.
Datum vložení: 8.7.2005 9:01:54
Duvod je IMHO celkem prosty - connection pooling. Pri volani metody Close na instanci connection nedochazi pri pouziti poolingu k fyzickemu zavreni spojeni, ale k jeho vraceni do poolu. Diky tomu je mozne aplikaci daleko lepe skalovat, protoze spojeni jsou vyuzivana efektivne pouze tehdy kdyz jsou potreba. Pokud je zavirat nebudu, tak v podstate kazdy klient musi mit svoje spojeni do DB, coz pri vice klientech muze byt docela problem. Viz napr. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/daag.asp , sekce "Managing Database Connections" a take kapitolka "Connection Usage Patterns" tamtez.