rarouš.weblog - komentáře k článku

Komentář k článku Doménové dotazy

Steve — Sun, 31 Jan 2010 12:00:03 GMT

Vypadá to hezky, díky práci nad IQueryable<> není implementace Query objektu závislá na použitém ORM a mohli bychom teoreticky Query objekty implementovat i v rámci aplikační vrstvy/fasády pro ní.

S čím bych měl možná u takového řešení problém je, že IQueryable<> jako zdroj pro query object podle mě nemusí stačit (nebo ano?), někdy by člověk chtěl udělat takový dotaz, který NHibernate.Linq (resp. Criteria API) rozvine v nějaké strašné SQL, ručně v raw SQL, někdy by člověk chtěl využít specifik dané databáze jako třeba hierarchy id…

Možností by bylo jako parametr pro Fetch nabídnou ISession, ale to zase ztrácíme nezávislost na ORM/databázi…

mimochodem bitva repository/DAO/Query objects je trefně popsaná na nhforge

Komentář k článku Doménové dotazy

Aleš Roubíček — Sun, 31 Jan 2010 13:16:01 GMT

[1] Steve: Použití IQueryable je specifické pro tento příklad, klidně na vstupu může být ISession nebo DbConnection to už je implementační detail. :)

Strašnému SQL generovanému ORM nástrojem se dá předejít správným mapováním. K tomu nám může pomoci např. NHProf nebo podobný nástroj.

Nezávislost na ORM je ve většině případů zcela zbytečná. Jen málo aplikací bude potřebovat nezávislost na ORM, či konkrétním DB stroji.

Komentář k článku Doménové dotazy

Augi — Sun, 31 Jan 2010 17:36:24 GMT

A ten IQueryExecutor používáš jako generickou náhradu Repository?

Komentář k článku Doménové dotazy

Steve — Sun, 31 Jan 2010 18:00:54 GMT

[2] Aleš Roubíček: Když ale použiji ISession (DbConnection), tak bych měl mít, podle mého názoru, Query objekty v datové vrstvě, potom ale vznikne přímá závistost aplikační vrstvy na té datové (narozdíl od DAO nebo repository objektů-k těm přistupuji přes interface).

Myšlenka Query objektů se mi líbí, ale s tahle závislost mi trochu vadí a zajímá mne, jestli je nějak řešitelná… Možná je problém ve snaze o „čistotu“ návrhu za každou cenu a přitom by mohlo být efektivní udělat občas takový malý ústupek…

Komentář k článku Doménové dotazy

Aleš Roubíček — Sun, 31 Jan 2010 21:30:31 GMT

[3] Augi: U mne je IRepository<T> zdrojem dodávajícím IQueryable<T> pro IQueryExecutor<T>. Což neni úplně čisté řešení, ale je dané historicky evolucí projektu. :)

[4] Steve: Otázka je, co považuješ za datovou vrstvu. Pro někoho to je databáze, pro jiného ADO.NET, pro dalšího ORM Framework… Osobně jsem na úrovni abstrakce s IQueryable. Vzhledem k tomu, že používám Castle ActiveRecord, je mapování součástí mého doménového modelu, který prosakuje i do views. Žádný problém s tím nemám. Ani problémy s čistotou. Spíš bych pak měl problém s překompikovaností.

Komentář k článku Doménové dotazy

Besnik — Mon, 13 Sep 2010 14:56:05 GMT

Zdar, tento problem sa snazim riesit cez generic repository a specification pattern, nieco o tom som popisal tu http://besnikgeek.blogspot.com/…s-query.html.

V zmysle OCP data z repozitara tahas takto (priklad z http://code.google.com/…crepository/):

ICustomerRepository
customerRepository =
this.IoC.Resolve<ICustomerRepository>(unitOfWork,
specificationLocator);

IList<Customer> =
customerRepository.Specify<ICustomerSpecification>()
.NameStartsWith("Ales")
.OlderThan(18)
.ToResult()
.Take(3)
.ToList();

Komentář k článku Doménové dotazy

Augi — Wed, 02 Feb 2011 16:56:08 GMT

[4]Aleš to má jednoduchý, protože používá IQueryable, které si může dovolit pronést skrze všechny vrstvy.

Pokud ale chceme pracovat jinak (ne s IQueryable), tak je IMHO potřeba důsledně oddělit „popis dotazu“ (ten je v doménové/aplikační vrstvě) a „vykonání dotazu“ – to je úkol infrastrukturního kódu (tedy repository), který musí umět dotaz správně interpretovat (tj. převést ho do správného LINQ dotazu, SQL dotazu apod.). Za takový obecný popis dotazu lze považovat expression trees, čímž se dostaneme jen o jednu úroveň níž než je IQueryable.

Taková repository by měla interface, jehož zásadní metoda by vypadala takto:

IEnumerable<TResult> Fetch<TResult>(Expression<Func<IQueryable<T>, IQueryable<TResult>>> query);

Komentář k článku Doménové dotazy

Tim — Wed, 14 Dec 2011 09:41:40 GMT

Ahoj, doménové dotazy se mi moc líbí. Nemůžu se ale nějak vypořádat s tím, že na rozdíl od použití repository, tak jak je nahoře, musím do Query vytáhnout všechny „tabuky“ (IQueryable objekty), nad kterými stavím dotaz. Primárně by mi to nevadilo a těžko bych asi psal dotaz, když by nebylo nad čím ho psát. Otázkou je, jak je mám do toho Query dostat?

Pokud například potřebuji QueryObjekt, který by z knihovny vyndal seznam knih od anglického autora, mohlo by to vypadat následovně?

class BooksByAuthorNationalityQuery {

public virtual IEnumerable<Book> Fetch(IQueryable<Book> bookTable, IQueryable<AuthorOfBook> authorOfBookTable, IQueryable<Author> AuthorTable) {
 // return fetch z CreateQuery:
 // join tabulek, where podle nationality, select Book.
 } 
}

Pro tenhle QueryObjekt, už ale nepoužiji IQueryExecutor a musím vytvořit extra IBookAndAutorQueryExecutor. Ve finále se mi pak repository, tak jak je nahoře rozpadne na Query objekty a ne o mnoho méně „specializovaných“ QueryExecutor oběktů. To ale můžu rovnou udělat „specializované“ repository IBookByAuthorNationalityRepository s metodou Fetch().

Mám takový pocit, že tohle už někdo musel řešit a že mi něco uniká. Děkuji za nakopnutí správným směrem:)

Komentář k článku Doménové dotazy

Aleš Roubíček — Sat, 17 Dec 2011 12:08:56 GMT

Přemýšlíš příliš relačně. Ve většině případů, bude mít objekt Book vazbu na Autora a z něj můžeš skládat dotaz bez problémů. Vždy záleží na tom, jak máš namodelovaný objektový model.

Komentář k článku Doménové dotazy

Ben — Thu, 22 Dec 2011 09:25:11 GMT

Mohl bys zde dat i implementaci IQueryExecutor pro výše popsány Article, prosím?

Komentář k článku Doménové dotazy

Aleš Roubíček — Thu, 22 Dec 2011 09:45:11 GMT

[10] Implementace je závislá na konkrétní použité technologii. Tady ukázka z hlavy pro EF:

public class ArticlesQueryExecutor : IQueryExecutor<Article> {
  readonly DbContext dbContext;

  public ArticlesQueryExecutor(DbContext dbContext) {
    this.dbContext = dbContext;
  }

  public int Count(IQueryObject<Article> query) {
    return query.Count(dbContext.Set<Article>());
  }

  public IEnumerable<Article> Fetch(IQueryObject<Article> query) {
    return query.Fetch(dbContext.Set<Article>());
  }

  public Article FetchOne(IQueryObject<Article> query) {
    return query.FetchOne(dbContext.Set<Article>());
  }

Jak vidíš, je to opravdu jednoduchý kód.

Komentář k článku Doménové dotazy

Ben — Thu, 22 Dec 2011 12:36:21 GMT

[11] diky moc! Jen mi tu schází jedna věc – pokud se nejedna o web aplikaci, kde životnost dbcontextu je dana nejakym injektorem – kde uzavírám připojeni na db?

Komentář k článku Doménové dotazy

Aleš Roubíček — Thu, 22 Dec 2011 13:20:57 GMT

To záleží v jakém scope připojení otevíráš. Injektovat můžeš i v newebových aplikacích.

Komentář k článku Doménové dotazy

Ben — Thu, 22 Dec 2011 16:01:49 GMT

[13] Ad scope) U web aplikací je to snadné, scope je dán requestem. U windows services +/- taky, ale u standardní Windows aplikace je to složitější. Taky se mi moc nelíbí, že aplikační vrstva je „zaprasena“ znalostí DbContextu (v tomto případě). Sám jsem to řešil tak, že jsem pracoval s repository vždy v rámci sekce using: using (var repository = new ArticleRepository) {…}, kde v metodě Dispose() bylo uzavření spojení s DB.

Jinak ještě jeden dotaz – kde jsou metody pro vytvoření, update a smazání objektu?

Komentář k článku Doménové dotazy

Aleš Roubíček — Fri, 23 Dec 2011 08:31:50 GMT

Vytváření, update a mazání nemaj s dotazováním nic společnýho. To je zodpovědnost Unit of Work. Tj. v případě EF DbContextu.