Visual studio C# ms sql
2016-04-02T22:53:59+02:00
2016-04-03T18:10:47+02:00
2022-07-19T03:42:54+02:00
  • Igazából azt kekl ekdontened, hogy a logikát hol akarod megvalósítani. Ha efben csinálod akkor ugye a szerverről abba a rétegbe kerül a logika, ahol az ef-t használod. Ha sok és bonyolult logika és nagy adathalmazon kell csinálni akkor érdemesebb sp-ben. De mondom vegyesen is lehet használni nem csak táblákkal megy az ef.
    Mutasd a teljes hozzászólást!
  • Az mennyire helytálló hogy az EF-ös, DbContext-es lekérdezés jóval lassabb, mint az sp-be írt, sql-t közvetlen hívó?

    Így ebben a fromában semmennyire. Tudok én olyan xar SQL eljárást is írni, aminél EF 100x gyorsabbat szül. Akkor lesz feltűnő, amikor már törni kell a buksit akár a linq kifejezésen, akár az SQL mondaton. Ekkor lehet, hogy nem a legoptimálisabb SQL-t fogja generálni, tehát alap eseteknél nem lesz gond (én EF6-al nrem nagyon foglalkoztam, EF7-el nyomulok most, eddig nem láttam olyan SQL lekérdezést, amitől égnek állna a hajam.)

    DbContext-nél például gondolom nem kapok visszajelzés, mit kellene indexelnem, míg ms sql stored procedure-nál ezt ki tudom szűrni.

    Az EF által generált SQL-eket meg tudod nézni (így) ki tudod másolni és le tudod futtatni SSMS-ben. Nem egy űrtechnológia, szóval nem fog paraméterezéstől függő SQL-t gyártani, így ezt elég egyszer ellenőrizni (aztán persze később lehet, hogy más indexek kellenek, de a lekérdezés ugyan az lesz).

    Igazából az se egyértelmű, mennyi pluszköltséggel jár az EDMX használata.

    Elméletileg semekkor, gyakorlatilag meg attól függ, hogy mennyire bonyolult dolgokat szeretnél megvalósítani a DAL-ban. 

    Teszteljem mi a lassú ott használjak sp-t, a többin használjam EF-öt?

    Szerintem valahogy így. De ez sem igazán pontos, mert valójában ez a kérdés így hangzik:
    "Teszteljem mi a lassú ott használjak sp-t, a többin használjam Linq-t?"
    Mutasd a teljes hozzászólást!
  • Az mennyire helytálló hogy az EF-ös, DbContext-es lekérdezés jóval lassabb, mint az sp-be írt, sql-t közvetlen hívó? Vagy ez inkább csak a joinoknál feltűnő?

    DbContext-nél például gondolom nem kapok visszajelzés, mit kellene indexelnem, míg ms sql stored procedure-nál ezt ki tudom szűrni.



    Igazából az se egyértelmű, mennyi pluszköltséggel jár az EDMX használata.

    Jó lenne valami példa, mikor érdemes DbContext-et használni, mikor nem. Pontosabban ha együtt használható, hol érdemes váltani. Teszteljem mi a lassú ott használjak sp-t, a többin használjam EF-öt?
    Mutasd a teljes hozzászólást!
  • EF az alap művelettekkel nagyon jól elboldogul és egész jól fordít linq-ról SQL-re. A probléma az össszetettebb joinoknál lesz, ott előfordulhat, hogy nem a legoptimálisabb lekérdezést fogja gyártani, viszont ilyenkor magad is írhatsz lekérdezést és használhatod EF-en keresztül.

    Azt nem értem romezor miért keverte ide az sql injection-t. Azt ki tudod védeni paraméteres lekérdezésekkel akkor is ha mindenre saját SQL-t gyártasz.
    Mutasd a teljes hozzászólást!
  • Igen,  a like jó lesz.  De sima sqlben is kell tudni a típusokat.  Ha kényelmesebb neked,  akkor használj tárolt eljárásokat ef-ben.
    Pl:https://msdn.microsoft.com/en-us/data/gg699321.aspx

    Vagy ha kényelmesebbnek találod próbáld ki a Dappert :http://www.c-sharpcorner.com/UploadFile/e4e3f7/dapper-king-of-micro-orm-C-Sharp-net/

    Csak tartsd szem előtt,  hogy sp-t vagy parameterezett query-t hívj,  ne string műveletekkel összerakott lekerdezeseket.

    Pl ilyet ne var sql="select * from a where name like '"+valamivaltozo+"'"
    Mutasd a teljes hozzászólást!
  • Az alapcélom: Van VBAccess-ben egy céges adattároló, kezelő szoftver. Alkatrészek, Műveletek, Rendelések, Dolgozok, egyébb folyamatok, számlaírás, excelbe írás, stb...

    Ezt akarom C#-ba átírni
    Mutasd a teljes hozzászólást!
  • Én paraméterként szeretném megadni például mely oszlopra keressen. EF-ön ezt elég nehézkesnek láttam, listából kiválasztani az oszlopnevet, utána meg eldönteni, hogy most bool, int vagy mely tipusú az oszlop. EF-ben nem találtam a LIKE -al equivalens dolgot. contains kulcsszó boolra nem jó például.
    Mutasd a teljes hozzászólást!
  • Ez így nem igaz amit írtál.
    Ha sp-t használ és paramétereket nincs injection.
    Teljes szabadon választható hogy mit használ.  Mindkettőnek meg van a maga helye.  Nagy mennyiségű adattal nehéz az ef-t optimalizálni addig nincs gond míg néhány 10000 rekord van.  Természetesen lehet jól is írni,  csak tapasztalat kell hozzá,  láttam jól megirt ef kódot is.
    Tudom mindet használom...
    Ef,  dapper,  sqlclient stb.
    De EF+sp,  dapper+sp is használható kombináció.
    Mutasd a teljes hozzászólást!
  • Az Entity Framework olyan szempontból előnyös, hogy bármilyen, az elmúlt 5 évben íródott példakódot nézel, azt nagy valószínűséggel EF-hez írták, és valószínűleg a jövőben is ez lesz az irányadó.

    Saját kézzel ne írj lekérdezéseket. Biztos lesz olyan sztárprogramozó-adatbázis guru, aki fényképeket készített a hasmenéséről, amit az EF által generált SQL váltott ki nála, de ha soha nem csináltál ilyet, inkább hagyatkozz erre az extra absztrakcióra az adatbázisod felett. Az SQL injection valszeg még mindig a legnépszerűbb biztonsági kockázat. Az sem kifogás, hogy ez nem publikus oldal lesz, alig fogják használni, stb. Egyszer biztos fogsz olyat is írni, amit publikusan használnak és akkor egy potenciálisan "biztosnágtalan" alapról fogsz indulni.
    Mutasd a teljes hozzászólást!
  • Sziasztok! 
    Ms sql-ben van egy nagy adatbázisom.
    C#-ban írok hozzá szerkesztői felületet.

    A kérdésem az lenne, milyen pro-kontra érvek szólnak a LINQ vs DbContext, illetve az adatbázishoz írt közvetlen lekérdezés mellett-ellen?

    Próbálkozom, de nem igen értem mely irányt válasszam. Eddig EntityObject-et használtam, de nem vagyok biztos benne mennyire optimális
    Köszönöm
    Mutasd a teljes hozzászólást!
abcd