Tisti, ki ne glasujete za nikoli, lahko tudi napiĊĦete kaj uporabljate.
[Poll]
Avtor: MihaM, objavljeno na portalu SloDug.si (Arhiv)
Tisti, ki ne glasujete za nikoli, lahko tudi napiĊĦete kaj uporabljate.
[Poll]
MihaM - petek, 21. julij 2006
Ne bo ti žal. Stvar je fenomenalna. Delam že tri tedne s tem in mi je vedno bolj všeč.
AndrejT - petek, 21. julij 2006
MihaM:...dosti boljši... Si me takoj prepričal... Samo še malo časa najdem, da si ga *zares* pogledam...
MihaM - četrtek, 20. julij 2006
Sem zapustil XPO in preklopil na dosti boljši LLBLGen Pro.
MihaM - sreda, 28. junij 2006
spirit1: ne se ne splaca. ce bi kaj takega zacel razvijati sedaj. razvoje nase se je zacel takoj, ko je prisu .net 1.0 ven, tak da je to kar je takrat bila dobra poslovna odlocitev. Se pa strinjam da sedaj kaj takega ne bi bilo pametno... najbrz... Zanimivo. Jaz sem v tistem obdobju usmeril moči na generator ado.net kode.
spirit1 - sreda, 28. junij 2006
ne se ne splaca. ce bi kaj takega zacel razvijati sedaj. razvoje nase se je zacel takoj, ko je prisu .net 1.0 ven, tak da je to kar je takrat bila dobra poslovna odlocitev. Se pa strinjam da sedaj kaj takega ne bi bilo pametno... najbrz...
bojanv - sreda, 28. junij 2006
Samo jz ne razumem....zakaj bi poskusal narediti nekaj, kar je ze narejeno, ko lahko namesto, da razvijas lastnega frameworka, uporabis ta cas za piljenje aplikacije, da bo na koncu aplikacija napisana dobro in ne polno bugov? Zakaj odkrivat toplo vodo? Se res tok splaca?
AndrejT - sreda, 28. junij 2006
spirit1:sarkazem ali ne... res imamo vse pod kontrolo. Da se razumemo, ta framework, ki ga mamo je dokaj huda stvar in opztimizirana za delo z raznimi clusterji itd... Ne dvomim, da je produkt hud, in če imate čas in ljudi, ki njegov razvoj po potrebi furajo naprej, vsaka čast - dobri ste. Veliko podjetij je namreč pripravljeno investirati dosti preveč časa in denarja v lasten razvoj, na koncu pa so rezultati parcialni, pa še (pogojno uporaben) produkt uide kontroli.
spirit1 - torek, 27. junij 2006
AndrejT: Ja, ampak poglej... zdaj imajo vse stvari pod kontrolo in se lahko kadarkoli zakopljejo v kodo in dogradijo manjkajoče funkcionalnosti. Niso odvisni od drugih... /sarcasm off sarkazem ali ne... res imamo vse pod kontrolo. Da se razumemo, ta framework, ki ga mamo je dokaj huda stvar in opztimizirana za delo z raznimi clusterji itd... Sej tudi kot ORM ni toliko slab, vendar ugotovis, da je za drugace simple stvari cel hudic za narest.
MihaM - torek, 27. junij 2006
AndrejT: Ja, ampak poglej... zdaj imajo vse stvari pod kontrolo in se lahko kadarkoli zakopljejo v kodo in dogradijo manjkajoče funkcionalnosti. Niso odvisni od drugih... /sarcasm off Naslednja stopnja neodvisnosti je izgradnja lastnega programskega okolja, nato OS in na koncu bo "padel" še hardwer. :-P
AndrejT - torek, 27. junij 2006
MihaM:Tipično. Še kako tipično. Da firma prišpara nekaj 100€ za komercialni produkt raje zapravi groznega časa in sredstev, da razvije nekaj kar bi lahko dobila za zgoraj omenjeno cifro (pa še razvoj in podporo bi imeli). Ja, ampak poglej... zdaj imajo vse stvari pod kontrolo in se lahko kadarkoli zakopljejo v kodo in dogradijo manjkajoče funkcionalnosti. Niso odvisni od drugih... /sarcasm off
AndrejT - torek, 27. junij 2006
spirit1:Odvisno pac od designa... ceprav sem se vedno proti pisanju sql v aplikacijah to ce mene vprasas ni locevanje baze od aplikacije. Se strinjam in tukaj sem čisto s tabo... Na vsak način pa z ORM pridobijo predvsem developerji, ki se jim ne da ukvarjat z bazo ali T-SQLom (hm, oksimoron?), ker lahko živijo naprej s svojimi objekti, pa se jim ni treba ukvarjat z idejo, kako in kje so podatki zapisani. Kaj je lepšega, kot če lahko v kodi namesto selectov in insertov uporabljaš metode nad objekti?
MihaM - torek, 27. junij 2006
spirit1: Sej ga nismo nabavl. So ga razvil (se pred mojim casom). Tipično. Še kako tipično. Da firma prišpara nekaj 100€ za komercialni produkt raje zapravi groznega časa in sredstev, da razvije nekaj kar bi lahko dobila za zgoraj omenjeno cifro (pa še razvoj in podporo bi imeli). Kakorkoli, res, ORM ji so najbolj močni pri vnašanju/popravljanju podatkov, kjer ne potrebuješ kompliciranih selektov. Kam pišeš komplicirane selekte (baza ali aplikacija) je pa stvar navdiha (oba načina imata prednosti in slabosti). Npr. dinamični selekt (taki, kjer ne veš vseh pogojev vnaprej) je bolje pisati v aplikaciji.
spirit1 - torek, 27. junij 2006
No ja, tu bi se dalo ful debato udarit kako in kaj.... Odvisno pac od designa... ceprav sem se vedno proti pisanju sql v aplikacijah to ce mene vprasas ni locevanje baze od aplikacije. Sej ga nismo nabavl. So ga razvil (se pred mojim casom).
AndrejT - ponedeljek, 26. junij 2006
spirit1:Osebno sem izjemno proti kakrsnem koli dinamicnem grajenju sql-a s strani aplikacije. Zakaj? zato, ker potem ne mores querya spremeniti in optimizirati ali ga napisati lepse kar se skoraj vedno da. to se mi zdi edini tako vecji problem. Tu je več pristopov in verjetno noben ni čisto "pravi". Uporaba stored procedur bi lahko predstavljala problem za ORM, ker jih lahko napišeš tako, da niso v skladu, kar pričakuje mapper (predvsem write). Navsezadnje lahko tudi komplet vso programsko logiko zapišeš v procedure (kjer po možnosti pretežno uporabljaš kurzorje) in ti program služi samo kot dummy reader/writer. Zato, ultimativne rešitve zaenkrat še ni, in pa, kot praviš, ORMji morajo podpirati različne načine dostopov do baze, končna implementacija pa je stvar pameti razvijalca. Če boste razmišljali o nabavi še kakšnega produkta za pol mio eurov, pa kar sporoči
spirit1 - sobota, 24. junij 2006
pri nas imamo en tak "lep" ORM ki je stal pol milijona evrov za narest (don't ask) Zadeva je zakon in oh in sploh... ampak kaj ko pa ce hoces narest kej bolj kompliciranega ti pa vrze ven query z milijon nepotrebnimi joini ORM-ji so drugace kar v redu stvar in so kul za delat.... VENDAR... ORM MORA podpirati data access prek stored procedur. Osebno sem izjemno proti kakrsnem koli dinamicnem grajenju sql-a s strani aplikacije. Zakaj? zato, ker potem ne mores querya spremeniti in optimizirati ali ga napisati lepse kar se skoraj vedno da. to se mi zdi edini tako vecji problem.
MihaM - torek, 20. junij 2006
Moram priznat, da nisem pričakoval tako ignoriranje ORM produktov. Boste že vidli, ko pride DLinq ;-P
MihaM - ponedeljek, 05. junij 2006
Developer Express XPO. Preklopil na dosti boljši LLBLGen Pro.