BUTHRAKAUR: Naopak, efektivni to je naramne. Je to jako by jsi delal samostatnou vrstvu/knihovnu, ktera ma nejaky rozhrani. Dotycny rozhrani pak pouzivas. Pritom ty SQL objekty pises v necem, co je k tomu urceny a muzes vyuzivat vsechny vychytavky dotycny DB. Nejsi pak omezenej nejakym ORM ani to nemusis z pameti psat do nejakyho neudrzovatelnyho stringu.

EDISN: velmi prekvapive najdes trial na webu mathworksu. btw dost zvlastni otazka na C# diskuzi

Zdravím, nemáte někdo zkušební verzi Matlabu, nebo kde se dá funkční verze stáhnout? Díky

TENCOKACISTROMY: tak s tema view apod potom asi jo - s tim jsem nepocital, pze mi to nepripada z hlediska vyvoje efektivni na spravu a tak (ale to je OT) :) To pak jsou ty LINQ dotazy vazne primitivni a neni v tom asi problem - myslel jsem pripady, kdy se klasicky joinuje, nejaky agregace, subselecty a tak. Tam pak na linq a optimalni dotazy moc neverim..

BUTHRAKAUR: Tak ja stejne pouzivam view/tabulkovy-funkce/ulozeny-procedury a nasledne pak z selectuju z nich. Takze v tom LINQovym dotazu mam vetsinou jednoduchou WHERE podminku a nejaky ten ORDER BY.

Na nezavislost mezi aplikaci a databazi neverim, pokud zalezi na vykonnosti a DB se nepouziva jen jako "takovy-lepsi-soubor".

TENCOKACISTROMY: akorat mas pak jeste o neco mensi kontrolu nad vygenerovanym dotazem nez u vic low level dotazovacich nastroju IMO.. = SELECT N+1 apod radosti

tak nas MAGIC UNICORN je open-source :)

Entity Framework Magic Unicorn (and much more!) is now open source with take backs - Scott Hanselman
http://www.hanselman.com/blog/EntityFrameworkMagicUnicornAndMuchMoreIsNowOpenSourceWithTakeBacks.aspx

Entity Framework
http://entityframework.codeplex.com/

BUTHRAKAUR: dík za tip

BUTHRAKAUR: LINQ mi naopak pripada jako vybornej napad na dotazovani do DB. ze ten AST umi bejt komplikovanej je sice fakt, nicmene pokud se clovek prehoupne pres pocatecni zmateni, tak mi to prijde celkem ok. Navic uz jednou mi zachranil kuzi, kdy jsem diky nemu mohl dost snadno prejit z SqlCE na Db4O (jeste na starickym CF :)).

ESY: špatný klub, promiňte.

jo a ORM jsou nutny zlo, ktery zpusobili zli RDBMS marketingovy specialisti v boji proti objektovym/nerelacnim puristum! ;D

SAJAGI: v NH si muzes nadefinovat dodatecny DB funkce (v dialect nebo primo v dotazu pomoci Projections.SqlFunction()) - ty pak jdou pouzivat v criteria API/QueryOver, ale v NH Linq pochybuju.. Stejne je Linq na DB dotazovani prilis abstraktni zlo a podle tvy zminky o linq DB nahrazku v testech to trochu zavani :)

SAJAGI: No, to je takovej workaround. Vykonu to zrovan moc nepomuze.

P.S. me ORM nebavi, ale s nim je to tezky a bez nej peklo :)))

TENCOKACISTROMY: No, já v nhibernate nedělám zase tak dlouho, a google mi moc nepomohl. Víceméně podobnou záležitost (vyhledávání podle hashe) nakonec řešili všichni tím, že buď to v DB i v kódu převedli do stringu, nebo počítali hash v databázi (což pro mě není moc možnost, protože počítám hashe až z několika MB).

(mě to baví :D)

SAJAGI: nema nhibernate zpusob, jak oznacit nejakou metodu jako "preklad" do SQL? to bys pak mohl pouzit ten SequenceEqual.

(orm jsou zlo :D)

SAJAGI: Ještě detail, == nejspíš v DB fungovat bude, ale zas to vyhoří na unit testech, kdy se používá LINQ to Objects. Rád bych řešení, které vyhoví oběma...

Potřebuju v databázi vyhledávat podle sloupce typu binary(16) přes LINQ provider (nhibernate). SequenceEqual ale bohužel NHibernate nepodporuje. Napadá vás nějaké elegantní řešení (kromě změny typu v DB na varchar a převodu třeba do hexdec zápisu), jak toho dosáhnout?

ziskal jsem po App Excellence Labu token na registraci Windows 8 Metro aplikace do pre-RTM Windows 8 Store, tak kdyby nekoho zajimaly poznatky, co to obnasi a co bude dale probihat (a co nebude pod NDA :) ), tak se kdyztak ptejte :)

MORMEGIL: Jo mas pravdu, musis prepsat i to "==", zapomnel jsem to tam pripsat. Bylo prepsane oboje.

To je nějaká divná historka. Přepsání metody Equals samo o sobě nijak neovlivní chování operátoru ==. Pokud někdo napsal operátor == tak, že jenom volá to Equals na levém objektu, pak to ovšem chcípne na NullReferenceException (ve tvém případě nullového myArgument; ostatně Equals(null) musí vždy vracet false). V nějakém složitějším případě je pak chyba někde jinde.

Každopádně takováhle implementace Equals je blbě prostě proto, že to neplní kontrakt metody Equals, protože nikdy nevrátí true, které je však povinnou návratovou hodnotou pro x.Equals(x).