Azoknak ajánljuk, akik lekérdezéseket írnak az oldal kódjába...
Üdvözlök mindenkit!
Habréval kapcsolatban van néhány információ arról, hogy a VisualStudio 2008 következő verziójában az ADO.NET EntityFramework lesz. (Elárulok egy titkot, ez a verzió már megjelent.) Ez a fejlesztés egy univerzális keretrendszer, amely lehetővé teszi, hogy néhány egérkattintással adatlogikát hozzon létre a projekthez.
Eddig adatlogikával dolgozva 2 féle projekttel találkoztam. Az elsők a hírhedt NHibernate keretrendszeren készültek, a többit programozók valósították meg. Már 3 éve írok és fejlesztek különféle rendszereket, és ez idő alatt kizárólag ezekkel a fogantyúkkal való munka logikáját fejlesztem.
Így a minap, miután telepítettem egy új Windowst, letöltöttem a VisualStudio WebDeveloper Express-t, és boldogan találtam a csomagban az ADO.NET EntityFramework-et. Egy idő után regisztráltam egy domaint, létrehoztam egy egyszerű weboldalt, és elkezdtem edzeni az erőmet, hogy programokat írjak ehhez a kerethez.
Először létre kell hoznia egy egyszerű webprojektet adatbázissal. Az is jó lenne, ha a DataBase Exploreren keresztül azonnal csatlakozna az adatbázishoz. Később még kényelmesebb lesz.
Ezt követően egy új "ADO.NET Entity Data Model" elemet kell hozzáadni a projekthez.
A rendszernek meg kell adnia egy karakterláncot az adatbázishoz való csatlakozáshoz, valamint meg kell adnia, hogy honnan származik az első ADO.NET EF modell.
Az adatbázisomban már van két nagyon egyszerű Post és User tábla, így minden további nélkül rákényszerítettem a rendszert, hogy az adatbázisom alapján készítsen modellt. Mindezek után nagyon egyszerű műveletek, kaptam egy működő db modellt. Sőt, miután vizuálisan tanulmányoztam ezt a modellt, nem felejtettem el megnézni a kódot, és megnézni, hogyan írja le a keretrendszer az összes osztályomat?
- névtér DataBaseCore
- ///
- /// A sémában nincsenek megjegyzések a DbModelhez.
- ///
- nyilvános részleges osztály DbModel: global::System.Data.Objects.ObjectContext
- ///
- /// Inicializál egy új DbModel objektumot az alkalmazás konfigurációs fájljának "DbModel" szakaszában található kapcsolati karakterlánc használatával.
- ///
- public DbModel() :
- base("name=DbModel" , "DbModel")
- ez .OnContextCreated();
- /* Szükségtelennek vágva */
- nyilvános részleges osztály Bejegyzés: global::System.Data.Objects.DataClasses.EntityObject
- ///
- /// Hozzon létre egy új bejegyzés objektumot.
- ///
- /// Az azonosító kezdeti értéke.
- nyilvános statikus bejegyzés CreatePost(int id)
- Post post = new Post();
- post.Id = id;
- visszatérő posta;
Az adatlogikai szakember képzett szeme egy meglehetősen egyszerű és elegáns osztály jelenlétét mutatta meg, amely lehetővé tette a rendszerben lévő bejegyzésekkel és a felhasználókkal való munkát.
Nos, nos, már megvan a kód, csak el kell kezdeni használni. És itt feltárul előttünk az ASP.NET minden varázsa és lehetősége. Az oldalon számos adatforrás között láttam az Entity Data Source-t, amely örömmel szolgáltat adatokat osztályunk kérésére. Húzzuk az űrlapra, elindítjuk a beállítási varázslót, és gyorsan csatoljuk az adatforrást a bejegyzési táblázatunkhoz.
Kétségtelenül sokkal kellemesebb lett az ASPX kódban az adatrendezés leírása.
* Ezt a forráskódot a Source Code Highlighter kiemelte.
- < asp:EntityDataSource ID ="dsPosts" runat ="server" ConnectionString ="name=DbModel"
- DefaultContainerName ="DbModel" EntitySetName ="Bejegyzés" >
Mondhatni – kecsesen ragyog.
Miután az adatszolgáltató megjelenik az űrlapon, szükség van a fogyasztóra is. Anélkül, hogy ügyes lettem volna, hozzáadtam egy egyszerű kódot, amely egyszerűen megjeleníti az összes bejegyzést egymás után.
* Ezt a forráskódot a Source Code Highlighter kiemelte.
- < asp:Repeater runat ="server" ID ="repPosts" DataSourceID ="dsPosts" >
- < HeaderTemplate >
- < ItemTemplate >
- < div >
- < h3 >
- < asp:Label ID ="lblHeader" runat ="server" Text ="<%# Eval("Header") %>" >
- < p >
- < asp:Label ID ="lblText" runat ="server" Text ="<%# Helpers.TypographText(Eval("Text").ToString()) %>" >
És itt véget is ér a történetem legegyszerűbb része. Eddig mindent meg lehet ismételni az egérrel. Elég könnyű volt. Nemrég hoztuk létre az adatbázis objektumorientált nézetét, és ezzel a nézettel kezdtük meg az adatbázis adatainak megjelenítését az oldalon. Ugyanakkor soha nem írtunk egyetlen kérést, nem kaptunk adatokat közvetlenül az adatbázisból stb.
De mit jelenítsen meg a felhasználónak, ha nincs semmink az adatbázisban? Nem jó. Az adatbázis kitöltéséhez egy űrlapot kell írnia. Most kilépünk az egérprogramozásból, és elkezdjük írni a kódot.
Megcsináltam a két legalapvetőbb műveletet a rendszerben lévő bejegyzésekkel való munkához - ez a hozzáadás és a törlés. A kóddal analóg módon történő szerkesztés nem lesz nehéz senki számára.
* Ezt a forráskódot a Source Code Highlighter kiemelte.
- névtér DBW
- nyilvános osztály poszt
- nyilvános bejegyzés()
- public static void New (String PostText, String PostHeader, Int32 UserId)
- p.Header = Post Header;
- p.Text = Helpers.TypographText(PostText);
- p.PublishDate = DateTime.Now;
- p.User = (az m.User usr-ből ahol usr.Id == UserId válassza ki az usr-t).First();
- m.AddToPost(p);
- m.SaveChanges();
- public static void Törlés (Int32 PostId)
- DataBaseCore.DbModel m = new DataBaseCore.DbModel();
- DataBaseCore.Post p = new DataBaseCore.Post();
- p = (a pst-ből az m.Post-ban ahol pst.Id == PostId válassza ki a pst-t).First();
- m.DeleteObject(p);
- m.SaveChanges();
Úgy tűnik, hogy minden egyszerű, és igen, az is. De van egy-két árnyalat.
Először is, ez a LINQ. Enélkül az ADO.NET sehol. Tehát nem szabad kibújnia és általában pontszámot szereznie az SQL-en vagy a LINQ-n, továbbra is lekérdezéseket kell írnia.
Másodszor, ezt a kódot a keretrendszer automatikusan generálja, így bizonyos pontokon nem kell sok kényelemre számítanod, és mindig készen kell állnod a stúdió által már elkészített kód megváltoztatására. Például itt a 16. sorban kényelmesebb lenne nem egy user típusú objektumot használni, amit az adatbázisból kellett kiválasztanom, hanem azonnal átadnám a felhasználói azonosító értékét. Ennél a kódnál kényelmesebb lenne, de nem univerzális. Ezért a kódot javítani és újra kell gondolni. Talán csak nem felhasználói azonosítót kell átadnia, hanem egy user típusú objektumot.
Mi a következő lépés? Továbbra is folytatom a projekt megírását, belemerülve az ADO.NET Entity Framework vadjaiba, és szívesen megosztom veletek kutatásaimat, kedves habrauserek. Ennek megfelelően lesznek új cikkek, komolyabb és mélyebb adatokkal.
UPD. A téma nagyon tág. Itt még a lehetőségek százalékát sem hozzuk nyilvánosságra, de a folytatás 8-)
ADO technológiák.HÁLÓ, . NET Framework, CORBA
Az ADO .NET távoli adatbázis-elérési technológiát a kliens-szerver architektúrához is fejlesztették. A távoli adatbázisok két szintje – kliens és szerver – mellett további szintek jelennek meg – az alkalmazások üzleti logikáját megvalósító üzleti logikai szerverek.
Az ADO .NET technológia a következő sémát hozza létre az ügyfél számára az adatbázis-kiszolgálóval való együttműködéshez:
Kapcsolat létrehozása a szerverrel;
A szükséges adatok beszerzése;
A kapcsolat lezárása;
Adatfeldolgozás;
Kapcsolat létrehozása a megváltozott adatok kiszolgálóra való visszaküldéséhez.
Az ADO .NET két fő modulon alapul:
Adatszolgáltató .NET FrameWork
Rezidens relációs adatbázis (DataSet).
Adatszolgáltató, ahogy a neve is sugallja, felelős az alkalmazásnak az adatforrással való kommunikációjáért és az adatok manipulálásáért. Az adatszolgáltató a következő adatkezelési objektumokat tartalmazza:
a) A kapcsolat adatforrással való kapcsolat létrehozására, valamint tranzakciók kezelésére szolgál.
b) A parancs lehetővé teszi a forrásadatok kezelését, valamint a tárolt eljárások végrehajtását. Ebben az esetben mindkét irányú adatátvitel paraméterei használhatók.
c) A DataAdapter kapcsolatként szolgál a rezidens DataSet adatbázis és az adatforrás között, és általában a Command objektumot használja az SQL parancsok végrehajtására mind a DataSet adatokkal való feltöltésekor, mind a kliens által megváltoztatott adatok forrásba való visszaküldésekor. Négy módszerrel hajthatja végre ezeket a funkciókat: SelectCommand, InsertCommand, UpdateCommand és DeleteCommand.
d) A DataReader csak olvasható adatokat biztosít a forrásból. Ha a kliens alkalmazás nem módosítja az adatokat, és nem igényli az adatok tetszőleges kiválasztását, de elegendő egy egyszeri nézet, akkor a DataReader használata DataSet helyett számítógépes erőforrásokat takarít meg, valamint növeli az alkalmazás teljesítményét.
Rezidens relációs adatbázis a kliens által kapott relációs adatbázis, amely a rezidens RAM-jában van tárolva.
Továbbá a kliens offline feldolgozza az adatokat, szükség esetén módosítja azokat, majd újra létrejön a kapcsolat a szerverrel, és visszaküldésre kerül a módosított információ a rezidens adatbázisból.
Egy ilyen interakciós séma némileg hasonlít a fájlarchitektúra munkájához -
szerver, és a vállalatok gyakran használják, amikor távoli adatbázisokkal dolgoznak ezen keresztül globális hálózat Internet.
Ahhoz, hogy az ADO .NET részeként hozzáférjen az objektumokhoz a globális interneten keresztül, rendelkezésre áll a .NET FrameWork modul, amely interakciót biztosít a különféle adatmegjelenítési formátumok, köztük a HTML és az XML között.
Ezekből a jellemzőkből látható, hogy az ADO .NET technológia a következőket nyújtja:
Különféle formátumú adatok közötti interakció képessége, beleértve a HTML-t és az XML-t;
Jelentős költségmegtakarítás, ha távoli adatbázisokkal dolgozik a globális interneten keresztül.
Utolsó frissítés: 2015.10.31
Ma az adatokkal való munka nagy jelentőséggel bír. Adatok tárolására szolgál különféle rendszerek adatbázis-kezelés: MS SQL szerver, Oracle, MySQL és így tovább. És a legtöbb nagy alkalmazás ilyen vagy olyan módon használja ezeket az adatbázis-kezelő rendszereket az adatok tárolására. Az adatbázis és a C# alkalmazás közötti kommunikációhoz azonban közvetítőre van szükség. És éppen ilyen közvetítő az ADO.NET technológia.
Az ADO.NET olyan adattechnológiát biztosít, amely a .NET-keretrendszeren alapul. Ez a technológia egy sor osztályt ad nekünk, amelyeken keresztül lekérdezéseket küldhetünk adatbázisokhoz, kapcsolatokat létesíthetünk, választ kaphatunk az adatbázistól, és számos egyéb műveletet hajthatunk végre.
Ezenkívül fontos megjegyezni, hogy számos adatbázis-kezelő rendszer létezhet. Lényegében eltérhetnek egymástól. Az MS SQL Server például használja T-SQL nyelv, míg a MySQL és az Oracle PL-SQL-t használ. A különböző adatbázisrendszerek eltérő típusú adatokat tartalmazhatnak. Más pontok is eltérhetnek. Az ADO.NET funkcionalitása azonban úgy épül fel, hogy a fejlesztők számára egységes felületet biztosítson a legkülönfélébb DBMS-ekkel való munkavégzéshez.
Az ADO.NET adatbázis-felülete az objektumok korlátozott körén alapul: Connection, Command, DataReader, DataSet és DataAdapter. A Connection objektum kapcsolatot létesít az adatforrással. A Command objektum lehetővé teszi az adatbázisból származó adatokkal kapcsolatos műveletek végrehajtását. A DataReader objektum beolvassa a kérés eredményeként kapott adatokat. A DataSet objektumot úgy tervezték, hogy adatokat tároljon az adatbázisból, és lehetővé teszi, hogy az adatbázistól függetlenül dolgozzon velük. A DataAdapter objektum pedig közvetítő a DataSet és az adatforrás között. Főleg ezeken az objektumokon keresztül megy az adatbázissal való munka.
Annak érdekében azonban, hogy ugyanazt az objektumkészletet használjuk különböző adatforrásokhoz, megfelelő adatszolgáltató. Valójában az ADO.NET adatszolgáltatóján keresztül történik az adatbázissal való interakció. Ezenkívül az ADO.NET-ben minden adatforráshoz lehet saját szolgáltató, amely ténylegesen meghatározza a fenti osztályok konkrét megvalósítását.
Alapértelmezés szerint az ADO.NET a következő beépített szolgáltatókkal rendelkezik:
Az MS SQL Server szolgáltatója
Az OLE DB szolgáltatója (Hozzáférést biztosít az MS SQL Server néhány régi verziójához, valamint az Access, DB2, MySQL és Oracle adatbázisokhoz)
ODBC szolgáltató (azoknak az adatforrásoknak a szolgáltatója, amelyekhez nincs szolgáltató)
Szolgáltató az Oracle számára
EntityClient szolgáltató. Adatszolgáltató az ORM Entity Framework technológia számára
Az SQL Server Compact 4.0 Server szolgáltatója
Ezeken a beépített szolgáltatókon kívül sok más is létezik különféle adatbázisokhoz, például a MySQL-hez.
Az ADO.NET-ben használt fő névterek a következők:
System.Data: az ADO.NET architektúrát megvalósító osztályokat, interfészeket, delegáltakat határozza meg
System.Data.Common: az összes ADO.NET szolgáltatónál közös osztályokat tartalmaz
System.Data.Design: osztályokat határoz meg, amelyek saját adatkészleteik létrehozására szolgálnak
System.Data.Odbc: Meghatározza az ODBC adatszolgáltatójának funkcióit
System.Data.OleDb: Meghatározza az OLE DB adatszolgáltatójának funkcióit
System.Data.Sql: Az SQL Server specifikus funkcióit támogató osztályokat tárolja
System.Data.OracleClient: Meghatározza az Oracle adatbázisok szolgáltatói funkcióit
System.Data.SqlClient: az MS SQL Server adatbázisok szolgáltatói funkcióit határozza meg
System.Data.SqlServerCe: Az SQL Server Compact 4.0 szolgáltatói funkcióit határozza meg
System.Data.SqlTypes: osztályokat tartalmaz az MS SQL Server adattípusokhoz
Microsoft.SqlServer.Server: Az SQL Server összetevőit tárolja, hogy kommunikálhassanak a közös nyelvi futási környezettel
Sematikusan az ADO.NET architektúrája a következőképpen ábrázolható:
Funkcionálisan az ADO.NET osztályok két szintre bonthatók: csatlakoztatott és leválasztott szintre. Minden .NET adatszolgáltató megvalósítja a Connection, Command, DataReader, DataAdapter és számos egyéb objektum saját verzióját, amelyek a csatlakoztatott réteget alkotják. Vagyis ezek segítségével létrejön a kapcsolat az adatbázissal, és interakció történik vele. Általános szabály, hogy ezeknek az objektumoknak az egyes szolgáltatókhoz való implementációinak nevében van egy előtag, amely jelzi a szolgáltatót:
Más osztályok, mint például a DataSet, DataTable, DataRow, DataColumn és számos más osztály alkotják a leválasztott réteget, mivel az adatok lekérése után a DataSetbe, függetlenül attól, hogy a kapcsolat létrejött-e vagy sem, dolgozhatunk azokkal az adatokkal. Azaz az adatbázisból való adatok beérkezése után az alkalmazás leválasztható az adatforrásról.
Amikor az n-szintű architektúra építészei értékelnek egy új technológiát, mintát vagy stratégiát, eldöntik, hogy az új puzzle-darab hogyan fog illeszkedni az architektúrába. Ha van Entity Framework, az integráció nem okoz nehézséget. Integrálható n-szintű architektúrába, valamint egyrétegű architektúrába.
19.03.2009 15:32
Entity Framework GYIK
Az entitásmodellezés megértése, az ilyen modellek relációs adatbázisokhoz való hozzárendelése és az entitásadat-modellek (EDM) tervezése az Entitás-keretrendszer megértésének első lépései. Ezt a cikket azzal kezdem, hogy megválaszolom az Entity Framework alapjaival kapcsolatos kérdéseket, beleértve az ObjectContext osztályt, majd válaszolok a kérdésekre, hogy mikor és hol kell használni az Entity Client alkalmazást az Entity SQL-el. Ezen kívül azt tervezem, hogy elmagyarázom az EntityClient és az Object Services közötti különbséget, valamint a LINQ és az Entity SQL lekérdezések használatának következményeit ezekkel a szolgáltatásokkal együtt.
16.02.2009 15:15
Az ADO.NET entitáskeretrendszer áttekintése
Kiadásban vizuális Stúdió 2008-ban az ADO.NET új Entity Framework architektúrát vezet be. Lehetővé teszi a fejlesztők számára, hogy logikai vagy relációs adatmodell helyett objektummodell segítségével férhessenek hozzá az adatokhoz. Az Entity Framework segít az elvonatkoztatásban logikai diagram adatokat a fogalmi modellbe, és számos módot biztosít a koncepcionális modellel való interakcióra az Object Services és az EntityClient nevű új adatszolgáltatón keresztül. Az e havi cikk azt tárgyalja, hogy mi az Entity Framework, hogyan vonatkozik az alkalmazásokra, és hogyan lehet ennek szem előtt tartásával tervezni és programozni.
13.02.2009 18:44
Entitásadat-modell fejlesztése entitáskeretrendszerrel
Az entitáskeretrendszer az új technológia, az ADO.NET számára készült. Lehetővé teszi a fejlesztők számára, hogy fizikai modell helyett logikai modell segítségével vizualizálják az adatokat, ami némi fejlesztési rugalmasságot biztosít. A magazin 2007. júliusi számában az „Adatpontok” címszó alatt közöltük részletes áttekintést Entity Framework technológiák (hivatalosan 2008 első felében kell megjelennie).
13.02.2009 18:33
Attribútumok használata az üzleti entitások normalizálására és érvényesítésére
A vállalati programozásban egy adatelérési réteg tervezésekor gyakran felmerül az üzleti objektumokkal (üzleti entitásokkal) való munkavégzés kérdése: ezek a betöltés / módosítás / mentés és a szintek közötti mozgás. Ennek két fő módja van - saját üzleti entitások használata, ill szabvány azt jelenti(Az ADO.NET elég kényelmes módokat biztosít erre) - DataSet használatával.
20.01.2007 03:54
ADO.NET: Technológiai áttekintés
Sok programozó dolgozik adatbázisokkal Microsoft platformok, értékelni tudná az ADO technológia – ActiveX Data Objects – egyszerűségét és kényelmét. Az intuitív kezelőfelület és a logikus objektumok halmaza, valamint a programozás egyszerűsége méltán kapta a programozók elismerését. Ennek ellenére az új .NET platform mellett a Microsoft az adatbázis-elérési eszközök új generációját is bemutatja, az ADO.NET-et.
27.12.2006 01:32
Műveletek hierarchikus felépítésű adatokkal. Elosztott alkalmazások fejlesztése .NET-ben
Ez a cikk bemutatja a hierarchikus sorkészletek adatforrásban való olvasásának és írásának technikáját. Az ebben a cikkben található kódpéldákban az adatbázishoz való csatlakozáshoz Microsoft adatok Az SQL Server vagy a Microsoft Desktop Engine (MSDE) SQL által felügyelt szolgáltatót használ. Más OLEDB-kompatibilis adatforrásokhoz való csatlakozáshoz használja az ADO által felügyelt szolgáltatót.
27.12.2006 01:26
Offline adatok kezelése az ADO.NET-ben
Az ADO.NET-et, az ADO-val és az OLE DB-vel ellentétben, kifejezetten azokban való használatra tervezték webes alkalmazások, ahol nincs állandó kapcsolat az adatbázissal. Az adatokkal való hagyományos munka az ADO.NET-ben a következő séma szerint épül fel: Kapcsolat, akkor az Open metódussal megnyílik, egy Command objektum beágyazva jön létre SQL parancs, akkor lefut, majd a kapcsolat megszakad. Ez a megközelítés szálas hozzáférést biztosít a lekérdezések eredményeihez. Azok. ha DataReaderrel olvassa be az adatokat, nem ugorhat át több rekordon, és nem térhet vissza az előzőhöz. A streamelési hozzáférés maximális teljesítményt nyújt.
Betöltés...