NET Microsoft.Net Framework és programozása II

.Net 2 előadás jegyzet – 7. óra

1.oldal

.NET Microsoft .Net Framework és programozása II. Előadás jegyzet Előadó: Pócza Krisztián ELTE,2012

Egy 3 rétegű ASP .NET alkalmazás (4) Model View Controller (MVC) A Model View Controller a szoftvertervezésben használatos szerkezeti minta. Összetett, sok adatot a felhasználó elé táró számítógépes alkalmazásokban gyakori fejlesztői kívánalom az adathoz (modell) és a felhasználói felülethez (nézet) tartozó dolgok szétválasztása, hogy a felhasználói felület ne befolyásolja az adatkezelést, és az adatok átszervezhetők legyenek a felhasználói felület változtatása nélkül. A modell-nézet-vezérlő ezt úgy éri el, hogy elkülöníti az adatok elérését és az üzleti logikát az adatok megjelenítésétől és a felhasználói interakciótól egy közbülső összetevő, a vezérlő bevezetésével. Modell: Az alkalmazás által kezelt információk tartomány-specifikus ábrázolása. A tartománylogika jelentést ad a puszta adatnak (pl. kiszámolja, hogy a mai nap a felhasználó születésnapja-e, vagy az összeget, adókat és szállítási költségeket egy vásárlói kosár elemeihez). Sok alkalmazás használ állandó tároló eljárásokat (mint mondjuk egy adatbázis) adatok tárolásához. Az MNV nem említi külön az adatelérési réteget, mert ezt beleérti a modellbe. Nézet: Megjeleníti a modellt egy megfelelő alakban, mely alkalmas a felhasználói interakcióra, jellemzően egy felhasználói felületi elem képében. Különböző célokra különböző nézetek létezhetnek ugyanahhoz a modellhez. Vezérlő: Az eseményeket, jellemzően felhasználói műveleteket dolgozza fel és válaszol rájuk, illetve a modellben történő változásokat is kiválthat. Az MNV gyakran látható webalkalmazásokban, ahol a nézet az aktuális HTML oldal, a vezérlő pedig a kód, ami összegyűjti a dinamikus adatokat és létrehozza a HTML-ben a tartalmat. Végül a modellt a tartalom képviseli, ami általában adatbázisban vagy XML állományokban van tárolva.


2.oldal

A ComplexNetDemo bemutatása A ComplexNetDemo egy többrétegű alkalmazás. Az előző félév 9. előadásáról már ismerős lehet. Most a web alatti részeket vizsgáljuk meg. A program egyetemekkel és hallgatókkal foglalkozik. Egy egyetem és az ő egyik karának kiválasztása után tudjuk a hallgatókat különböző tulajdonságok alapján szűrni/szerkeszteni. Új hallgató létrehozásakor a validációs mezők értelemszerűen kitöltendők. Rétegek: Domain modell-entitites: milyen entitáson milyen szolgáltatások vannak? Adathozzáférési réteg: hogyan tartom a kapcsolatot az adatbázissal? Elvárás, hogy generikus adathozzáférési metódust alkalmazzunk! Logic - üzleti logika: ez a program lelke. Ez írja le, hogy milyen műveletek vannak. Foundation - infrastruktúra szolgáltatások: Ez egy külön projekt, ugyanis azt, hogy "Milyen infrastruktúrában fut a rendszer?" nem szabad összekeverni azzal, hogy "Mit csinál a rendszer?" Pl.: Milyen módon érem el az adatbázist? Hogyan végzem a validációt, tranzakciókezelést, loggolást, stb...?  nem írjuk bele a program logikáját leíró kódba! Értelemszerűen a rendszer lényege, hogy a különböző feladatokat külön komponensek végzik. Teszt: UNIT-teszt (ld. 11. előadás) WebUI és WPFUI két felhasználói felület, amely ugyanazt az üzleti logikát alkalmazza. Entities: Univercity.cs A DomainEntity egy ősosztály, amely egy ID -val rendelkezik. [Required2] - nem NULL és nem üres String -et vár [StringRange(2, 50)] - ez pedig 2-50 karakter hosszúságú bemenetet vár Megadható az entitás neve a fenti kikötésekkel. Faculty.cs Ez megmondja az ID -hoz tartozó nevet( [Required2], [StringRange(2, 50)] itt is él! ), illetve azt, hogy melyik egyetemen található az illető( [Required2] ). Student.cs Található benne egy csomó property (pl.: állandó és ideiglenes lakcím).


3.oldal

Address.cs IComplexType interface -t megvalósító osztály, amely egy olyan entitás, ami nem rendelkezik identitással(ld. előző félév). Adatbázis nyelvre lefordítva nem veszünk fel egy külön táblát és Foreign Key -el hivatkozunk rá, hanem egy valós érték. Azaz az itt található City, Street, StreetNumber egy-egy létező oszlop/attribútum lesz. Factory-Method pattern: public static Address Create(string city, string street, string streetNumber) { return new Address { City = city, Street = street, StreetNumber = streetNumber }; }

Logic: UniService.cs Két szolgáltatást tartalmaz: internal class UniServiceImpl : ImplServiceBase, IUniService

A konkrét műveletvégzés. Kilistázhatjuk az összes egyetemet, vagy lekérhetjük azt, amelynek az ID –ja megegyezik a paraméterként megadottal. internal class UniService : PublicServiceBase, IUniService

Ezek a szolgáltatások kívülről hívhatók. Fontos, hogy a kivételek megfelelően legyenek lekezelve, hiszen a felhasználó ezzel a szolgáltatással lép kapcsolatba. Magyarán problémaspecifikus exception –öket adjunk vissza, amiből valóban következtetni lehet a problémára. StudentService.cs public Student CreateStudent(Student student)

Itt hozhatunk létre új hallgatót, amennyiben átmegy a validáción. Végig megy az entitás összes property –jén és azok összes attributumán. További metódusok a különböző lekérdezésekhez. DataAccess: DataContext.cs Ez a következőt csinálja: Students = new StudentRepository(this); Universities = new UniversityRepository(this); Faculties = new FacultyRepository(this);

A StudentRepository.cs a Foundation –ben található RepositoryBase.cs absztrakt osztály leszármazottja és egyetlen metódust tartalmaz. RepositoryBase.cs –ben található számos lekérdező és módosító művelet generikusan megvalósítva. Ezek már konkrétan az adatbázisnak szólnak. Tehát van egy általános Repository tár, aminek segítségével lehet az adatokhoz hozzányúlni. Update művelet: betöltünk az adatbázisból egy értéket, módosítjuk, majd azt mondjuk, hogy DataContext.Save() (ez csak a megváltozott property –kkel foglalkozik).


4.oldal

A FeedReader bemutatása A FeedReader egy ASP .NET -ben írt RSS olvasó. A kódja megtalálható a honlapomon. (Illetve egy korábbi verziója ezen a címen: http://avalon.inf.elte.hu/edu/net2/Eladsok%20anyaga%20%2020062007%20II%20flv/07.%20 ASP.NET%20alapok%204,%20Web%20service-ek/FeedReader.zip ) Az RSS a Really Simple Syndication (körülbelül: nagyon egyszerű információ megosztás) rövidítése. Egy olyan XML alapú, szabványos formátumról van szó, amely lehetővé teszi, hogy egy webhely aktualitásait megossza a felhasználókkal anélkül, hogy közvetlenül meg kéne látogatnia az oldalt. Azaz ha keresünk egy hírt valamilyen témában, akkor nem kell végigböngészni az információs oldalakat, mint pl, Origo, Index, Hírszerző stb, hanem egy alkalmazással lekérjük az összes friss hírt. Magyarul a „pull” alapú információszerzési módszer „push”-ra cserélődik, azaz a távoli gép közvetíti az információt és nem mi megyünk el érte. Ilyen PL az Omea Reader is, ami egy ingyenes RSS olvasó: http://www.jetbrains.com/omea/reader/ FeedReader szerkezete A FeedReader.DataAccess alatt található két script. A Tables.sql script -tel létrehozhatjuk az adatbázis szerkezetét. Az adatbázis szerkezete elég egyszerű, mindössze 3 táblát tartalmaz: Feed, Item és ItemData. Az első tartalmazza az RSS Feed-et, ahonnan információt szeretnénk szerezni, a második a cikkek leírását tartalmazza, több részlettel, pl. szerző, időpont stb, a harmadik pedig magát az információt tárolja. Az alkalmazást több rétegű architektúraként építjük fel, hogy minnél rugalmasabb és testreszabhatóbb legyen. A főbb elemek a következők: 

FeedReader.DataAccess  Feladat az adatelérési metódusok implementálása. Ha változtatni szeretnénk az adatbázison (pl. MS SQL helyett Oracle -t alkalmazni), akkor ezen az összetevőn kell elvégezni a változtatásokat.



FeedReader.Documents  Az üzleti dokumentumainkat tartalmazó réteg. Mivel a többrétegű architektúrákat a .NET a szerializációval és a remoting -on keresztül támogatja, ezek a Business Objectek fognak „utazni” az egyes rétegek között, nem DataSetek. Ez sokkal hatékonyabb, mert nem kell cipelni extra infókat (mint pl. mezőnevek).



FeedReader.Services  Ez a rész tartalmazza az alkalmazásunk szolgáltatásait, mint pl. az üzleti auditálást.



Infrastructure  Ez az egyik legfontosabb rész, ugyanis a háromrétegű architekrúra minden rétegéhez alap- illetve segédosztályokat ad, amellyel a fejlesztés alapkoncepcióját is meghatározza.


5.oldal

Az Infrastructure főbb részei Nem tárgyaljuk ki teljes részletességében az alkalmazást, mert az sokáig tartana. Inkább az ASP.NET szempontjából fontos dolgokra koncetrálunk. Infrastructure.snk  A projekt Strong Name -je, ami egyértelműen azonosítja az assembly-t (erről már volt szó). Nem feltétlenül kötelező, de nagyvállalati környezetben igen. További infó a help -ben. Documents/Document  Ez az osztály egy ősosztálya a programunkban használatos Business Document -eknek. Néhány fontos attributumot, és egy interface -t is definiál, ami arra lesz jó nekünk, hogy a saját objektumaink tudják validálni magukat. Ebből fog származni majd az összes olyan objektumunk, aminek közlekednie kell a rétegek közt. DataAccess/IDBFunctions  Ez az interface definiál egy közös felületet, azoknak az alosztályoknak, amik majd az adatbáziskezelést fogják intézni. Bármilyen adatbázis motort fogunk is használni, tudnia kell mindazt, amik ebben vannak deklarálva (Pl. Megnyitás, Lezárás, Tranzakció indítása, stb.). DataAccess/MSSQLFunctions  Ez egy megvalósítása a fenti interface -nek, kifejezetten az MS SQL adatbáziskezelő motorra. Leginkább a megfelelő .NET-es osztály wrap -elése. DataAccess/LINQSQLFunctions  A program újabb (v2) verziójában LinQ alapú adatbázis elérést használunk. DataAccess/BaseDataContext  Ez egy IDBFunctions megvalósítást vár és az alap SQL technikák megvalósítási felületét adja meg. Mivel abstract, önmagában nem használható, származtatnunk kell belőle. FeedReader.DataAccess/DataContext.cs  Ez az osztály bővíti ki a fent említett osztály szolgáltatásait. Figyeljük meg, hogy itt már nincsenek beleégetve a kódba adatbázis specifikus elemek, mert ezt majd a konstruktorában kapja meg (IDBFunctions), amit továbbküld az ősosztálynak is. Itt az IDBFunctions interface SetDocumentField eljárását használjuk arra, hogy egy IDataReder-ből kiolvassuk és egy Business Document -be töltsük a megfelelő mezőt. Ez rugalmas, mert itt sem az adatbázis, sem a konkrét Business Document nincs rögzítve. Egyszerűen megváltoztatva a DataContext -et a kód átírása nélkül is működni fog. FeedReader.Services/Service.cs  Absztrakt osztály, ami a szolgáltatások felületét adja meg úgy, hogy a szolgáltatás független maradjon a fizikai rétegtől. A GetContextObject() függvény kéri el az aktuális adatbázis környezetet és építi fel a kapcsolatot az Activator.CreateInstance függvénnyel.

Validáció  A validációt alapvetően a Business Document Validate függvénye végzi el, de vannak validációs attributumok is, amik a property -kre tesznek feltételeket (pl. KeyFieldAttribute, RequiredAttribute, MinLengthAttribute Ezzel előírhatjuk pl. valaminek a minimális hosszát, vagy egy property kitöltése kötelező legyen).


6.oldal

Infrastructure.Documents DocumentContainer  Ez minden olyan collection ősosztálya, ami majd (Business) Document -eket fog tartalmazni. Ez is tudja validálni önmagát. Nyilván úgy, hogy végigmegy az elemein, és mivel azok Document -ek, meghívja mindegyik Validate függvényét. Infrastructure.Documents.ServiceFactory  Ez lényegében véve egy absztrakt gyártó tervminta leimplementálása. Service -eket csak ezen a ServiceFactory -n keresztül hozhatunk létre a CreateServiceByType hívással. Template mező hozzáadása grid -hez Ha megnézzük a Default.aspx -en levő gridet észrevehetjük, hogy nem csak egy sima grid, hanem template field -eket is tartalmaz. A template field -ekkel gyorsan javíthatjuk ASP -s alkalmazásunk kinézetét. A GridView gyorsszerkesztő menüjében az Edit Columns -ra kattintva adhatunk hozzá mezőt, majd ott a Convert this field into TemplateField gombbal alakíthatjuk sablon mezővé. A gvFeed is ezt a módszert használja tartalma megjelenítésére. Beadandó feladat lehetőség A FeedReader alkalmazás, vagy a Business Framework bővítése különféle komponensekkel. Például bővíthető egy rendes loggolási komponenssel. (további információ a tárgy előadójánál) Aspektus orientált programozás Az aspektusok olyan funkcionálisan összefüggõ programrészletek gyűjteményei, amelyek az AOP lehetõségeket nélkülözõ nyelven írt programban a forráskód különbözõ részein szétszórtan találhatóak meg. A paradigma célja, hogy ezen funkcionálisan összefüggõ részek egy helyre gyűjtésével a program bonyolultságát csökkentse, a karbantarthatóságát, olvashatóságát pedig javítsa. A lényeg, ami minden aspektus-orientált megközelítésben közös, hogy az osztályok mellett új modularizációs elemeket vezetnek be (aspect, subject stb.), melynek feladata, hogy az osztályoktól külön, azokból kivonva valósítsa meg az egyes aspektusok funkcionalitását. A rendszerre ortogonális dolgokat valósít meg. Microsoft program még nincs erre, de vannak third party szoftverek. Ezek az assembly -ket módosítják. Informatikai rendszerek összekapcsolása Service Oriented Architecture (SOA)  Szolgáltatás Orinteált Architektúra Minden alkalmazás önálló entitás, explicit interface -t ad a hozzá kapcsolódó másik egységnek (szerződések szükségesek). Másik marketing elnevezése is van mostanában ennek a technológiának: SaaS az Software as a Service arra öszpontosítva, hogy a programot mint egy szolgáltatást kell elképzelni (SOA kiterjesztése). Fontos hogy: - entitások vannak - üzleti objektumok vándoroljanak, ne az adat - explicit interface

.Net 2 előadás jegyzet – 7. óra -

7.oldal

szerződés

Rendszerek összekapcsolása .NET -ben Kétféle megoldás van:  Web Service –ek  szabványos megoldás  .NET remoting  nem szabványos, de két .NETes alkalmazás esetén gyors Web service SOAP  Simple Object Access Protocol A webservice hívások szabványos, XML alapú átviteli protokollja. E fölé kerül a kommunikációs protokoll. Leggyakrabban HTTP, ezért Web Service (webszolgáltatás). WSDL  Web service Description Language A hívható metódusok, paraméterek, és visszatérési értekek leírására szolgáló szabványos XML alapú nyelv.

NET Microsoft.Net Framework és programozása II

Recommend Documents