Új hozzászólás Aktív témák

• martonx veterán

  #9902

  #9893 akrobet

  2016-06-13 10:49:30

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  martonx

  veterán

  #9893 akrobet

  #9893 akrobet

  Akkor let's agree to disagree Értem én hogy sql-ben érdemes olyan részeit az alkalmazásnak átírni ami a legtöbbet használt és EF nem képes rá megfelelően gyorsan futó query-ket generálni.

  De mit csinálsz ha váltani kell egy másik providerre, neaggyisten valamilyen no-sql megoldásra?

  Nem lehetetlen SQL-ben megírt kódot tesztelni, karbantartani, csak nagyon hamar el fog menni tőle a kedved, ha egy olyan business model-ed van, ami kb 300 egyedi entitásból áll 15+ level mélységű relationokkel...

  "De mit csinálsz ha váltani kell egy másik providerre, neaggyisten valamilyen no-sql megoldásra?" - ok tegye fel a kezét, aki naponta vált MS SQL-ről Oracle-re és vissza SQL - NoSQL pedig még ORM-el sem átjárható, mivel teljesen más szemléletmódot, felhasználást várnak el.
  Egy programnál mindig el kell dönteni, hogy milyen infrastruktúrán fog futni, és utána abból kihozni a legjobbat. Tipikus félreértés, hogy az ORM azért jó, mert elfedi a DB layert, és könnyű átjárhatóságot biztosít (az meg még nagyobb félreértés, hogy SQL - NoSQL átjárhatóságot is biztosítana). Mármint az átjárhatóság SQL-en belül még nagyjából igaz is, de ennek csak akkor van szerepe, ha az ember tudatosan, direkt pont olyan rendszert fejleszt, amit kb. bárhova el akar adni, és célja, hogy Oracle, MySql, PostgeSQL, MS Sql, bármilyen SQL felett tudjon működni a rendszere. Ebben az esetben némi plusz munkával valóban meg lehet írni ORM-el úgy a rendszert, hogy az tökéletesen átjárható legyen.
  ORM-et elsősorban inkább azért használunk, mert kényelmes vele dolgozni, a kód valóban olvashatóbb lesz tőle, de fontos, hogy folyamatosan tartsuk szem előtt, hogy az ORM csak egy eszköz, és nagyon könnyen hibás architektúrákhoz vezethet, ha csak és kizárólag egy ORM-re alapozva fejlesztünk. Erre tökéletes példák vagytok ti.

  Ez az SQL-ben legyen logika dolog teljesen eset függő, nincs rá jó válasz. Én az általad megfogalmazott problémával kapcsolatban mondtam, hogy ebben az esetben szerintem tipikusan sokkal jobb megoldás tud lenni, ha komolyabban az SQL-re bízná magát az ember, és komolyabban elgondolkodna az SQL-ben való adatmodellezésen (nem is feltétlenül érdemi logikának kellene talán az SQL-ben lenni, egyszerűen csak végre komolyabban kellene gondolni, tervezni az SQL oldalon is a tábla struktúrákat, amikkel a várt dinamikus szabály rendszert könnyen lehetne modellezni, majd azt utána C# oldalon felhasználni).
  Pláne amikor későbbi hszediből ki is derült, hogy a DB-t tényleg ahogy esik, úgy puffan alapon használjátok, szóval egyre biztosabb vagyok a meglátásom helyességében.
  Szóval nem akarok olyan erős kijelentéseket tenni, hogy csak így, vagy csak úgy a jó, az elmúlt pár évben mindkét megoldást használtam, mindig azt amire éppen az adott esetben szükség volt.

  Főállásomban pont az elmúlt években volt / van egy ilyen komolyabb szemléletváltás, amikor az eredetileg mindent EF-el oldjunk meg, és kapja meg az adatot a C#, aztán majd abban jobban feldolgozzuk szemléletet a több milliárd adatsoros tábláknál már fel kellett, hogy váltsa az "oké, akkor amit lehet SQL oldalon oldjunk meg, de azért amit nem muszáj, az menjen továbbra is EF-el" szemlélet. Hidd el, pont ugyanúgy lehet mindent tesztelni SQL felhasználása mellett is, csak mondjuk egy teszt nem 5 másodpercig fog futni, hanem fél percig. De ha elég jól párhuzamosítod őket, akkor végül időben se tart feltétlenül tovább.
  Minden csak hozzáállás kérdése, még az általad felvázolt alapvetően hibásnak tűnő architektúra is valószínűleg tesztelhető maradna némi refaktorálás után, megfelelő mockolásokkal.

Új hozzászólás Aktív témák