Barátok Csala Péter webfejlesztő

Tartalom (Problem – Design – Solution) Hogyan kezdjünk hozzá? Adatbázis megtervezése – Hogyan érdemes implementálni a barátság modellt? – Mire ügyeljünk tervezéskor? Adatok lekérése az adatbázisból Adatok megjelenítése Adatbázis optimalizáció

Hogyan kezdjünk hozzá? Határozzunk meg mivel és mit szeretnénk csinálni – Ezt hívjuk modell alkotásnak – Milyen objektumokkal fogunk dolgozni Felhasználók – Milyen műveletek lesznek az objektumokhoz Barátság kérvényezés, elfogadás, felbontás Megj.: Alkalmazáshoz készítjük az adatbázist és nem fordítva!

Hogyan tároljuk el az információkat? A Felhasználó tábla kiegészítése – Barát1, Barát2, … Barát50, stb. Ne korlátozzuk a barátok számát! – Barátság és Felhasználó külön szedése – 2-sok kapcsolat Egy felhasználóhoz sok barátság rekord tartozhat Egy barátsághoz két ember kell Felhasználónként 1-1 barátság rekord? – Nem, elég egy fél rekord is! WTF?

Egy kis matek Tekintsünk a barátságra, mint egy relációra – Friends(a,b) Mit tudunk róla? – Tranzitív? Friends(a,b) + Friends(b,c) !=> Friends(a,c) Láncolás kilőve… – Kommutatív? Friends(a,b) = Friends(b,a) Két felhasználóhoz elég egy barátság rekord!

Barátságról információk Kik barátok √ – A 2 résztvevőre egy-egy mutató Barátság állapota – Barátságokon értelmezett műveletekhez kérvényezés, elfogadás, felbontás – Lehetséges állapotok Kérvény elküldve, de még nincs elfogadva (Waiting) Kérvény elküldve és elfogadva (Accepted) Barátság felbontása (Broken)

Az Adatbázisunk CREATE TABLE [dbo].[Relationships] ( Id int IDENTITY(1,1) NOT NULL PRIMARY KEY, ApplicantID int NOT NULL, PersonID int NOT NULL, Accepted smallint NULL, )

Mire ügyeljünk tervezéskor? Beszédes nevek választása – Angol esetén: figyeljünk az egyes és többes számra Megfelelő adattípusok használata – Mindig a legszűkebb olyan halmazt válasszuk, amibe még belefér a tárolandó adat (pl.: smallint) Minimalizáljuk a duplikált adatokat Gondoljunk a jövőre is! Okosan válasszuk meg a kulcsokat/indexeket

Kulcsok Két tábla összekapcsolására használjuk őket 1-sok kapcsolatnál megköveteljük az egyediséget Kulcstípusok – Természetes kulcsok (Intelligent Key) Egy vagy több mező alapján – Helyettesítő kulcsok (Surrogate Key) Rendszer által generált értékek AutoIncrement, GUID

Demó Barátság tábla létrehozása

Adatbázis elérése Linq To Sql – Adatbázis objektumokból.NET entitások – (LinqDataSource) Fölötte a DAL – Data Access Layer (Adatelérési réteg) Egyszerű statikus osztály/statikus metódusokkal Repository gyűjtemény (IRepository + SDSRepository) – Kódból is használható, illetve ObjectDataSource- szal is

Hogy néz ki egy Repository? CRUD műveletek vannak benne – Create, Retrieve ( = Select), Update, Delete Create pl.: NewObject(string name, …) Retrieve pl.: GetObjectById(int _id), GetAllObjects() – Filter, Query, Paging Update pl.: SaveObject(Something _s) Delete pl.: RemoveObject(Something _s) Egy interfészen keresztül definiáljuk – Könnyen cserélhető >> könnyen tesztelhető

Rétegek egymásra épülése

Demó DAL elkészítése

Adatmegjelenítés/Adatkötés Adatbázisbeli információk felhasználó felülethez történő kapcsolása – Pl.: Text= //one-way binding (Létezik kétirányú adatkötés is: Bind()) – Több rekord egyidejű megjelenítése esetén Visszavezetés egyszerű adatkötésre ItemTemplate (Listás ábrázolás) ColumnTemplate/FieldTemplate (Táblás reprezentáció)

ItemTemplate >> User Control Név: Életkor: ">Tovább... Ez is HTML kód. Csomagoljuk be egy „mini” oldalként = UserControl

Egyedi vezérlők UserControl/(Page fragment) (*.ascx) – Mini oldal, amely beágyazható más oldalakba – Ugyanúgy van markup és code-behind CompositeControl (*.cs >> dll) – Több vezérlő együttese – Nekünk kell megadnunk kódból a renderelt html-t CustomControl (*.cs >> dll) – Egy egyedi vezérlő – Új funkcionalitás

Egyedi vezérlők előnyei Újrahasznosíthatóság Kiterjeszthetőség Templatezhetőség Könnyű hordozhatóság

Demó Megjelenítési réteg

Barátságok kezelése automatával I. Friends.aspx?Mode={add|remove|accept}&Id ={1..} Kapcsolódó probléma: Barát kérvényezés gomb megjelenése, amikor nem kéne – Mi megoldásunk: Gomb megjelenik, ha már barát, akkor nem történik semmi Nem túl felhasználó barát meo.  – Javítás: Csak ott jelenjen meg a gomb, ahol kell is

Barátságok kezelése automatával II. – Javítás: Csak ott jelenjen meg a gomb, ahol kell is Megoldás: – ItemDataBound eseménykor kontrolláljuk a megjelenést – Lekérdezzük, hogy barátok-e, ha igen, akkor Visibilty=false – Túlságosan adatbázis igényes egyesével lekérdezgetni Megoldás javítása: – Először lekérjük az összes barátunkat – Eltároljuk egy ideiglenes tárolóban – Majd ennek segítségével hajtjuk végre a barátság vizsgálatot

Adatbázis optimalizáció Egy egyszerű példán keresztül – Hányan regisztráltak az oldalra? – Select Count(*) … >> költséges megoldás – Külön statisztika tábla (StatName, StatValue) SumRegUser:15670, FemaleUser:7817, (Male:rest) – 2 táblát kell most már így karbantartani Bonyolódik a DAL >> nem jó dolog  – Használjunk trigger-eket Insert, Update, Delete esetén módosítjuk a stat táblát is

Továbbfejlesztési lehetőségek Barát kérvényezésről értesítés Barát invitálás rendszeren kívülieknek Megismerkedési körülmények tárolása Mások barátainak megtekintése Csoport létrehozási lehetőség Nyitás a külvilág/fejlesztők felé (API) Friends.aspx?Mode=add&Id=1 cseréje Friends/add/1 (ASP.NET Routing) …

Elmélyülési javaslatok

Kérdések és válaszok 1) Mi az a Repository és mire jó? 2) Mire kell ügyelni egy adatbázis megtervezésekor? 3) Ti jöttök! 4)?