jeg har lavet en klasser som hedder DbHandler og alle database kald går i gennem denne klasse. så jeg troede at det var en facade klasse.
men efter at have kigget lidt på nettet har jeg lidt fået det indtryk, at der skal være en klasse mere, fx DbHanlderInterface for at der er tale om en facade.
her er et eksempel, som jeg har det nu:
public class Test { { private Page_Load(object sender, EventArgs e) { DbHandler db = new DbHandler(); strTest = db.GetName(); } } }
public class DbHanlder { { public String GetName() { bla bla sql kald til database; return Name; } } }
Jeg troede at DbHandler var en facade. Tager jeg fejl?
I dette særtema om aspekter af AI ser vi på skiftet fra sprogmodeller til AI-agenter, og hvordan virksomheder kan navigere i spændet mellem teknologisk hastighed og behovet for menneskelig kontrol.
Din egen klasse DBHandler er en facade. Den laver en grænse op til et andet lag ved at stille nogle metode til rådighed - og det kan man kalde facaden hertil.
Om din klasse så implementerer et interface, er ikke specielt for om man vil kalde det en "Facade".
En facadeklasse er, efter min bedste overbevisning, bare en klasse som samler/benytter funktionaliteten fra andre klasser (og derfor bliver endnu et abstrationslag ifht. databasen).
Som jeg ser dette koncept, så er det ret tæt på standard procedurale programmeringsprincipper - altså ikke noget helt nyt... altså ud over at det er pakket ind i klasser og har fået et "fint" navn :)
Med et facade mønstre forsimples (og begrænser) tilgangen til en gruppe af objekter, hvor man ikke har bruge for hele kompleksiteten.
Det er fint af starte din facade med et interface. Så kan du nemt skifte facade mønstret ud med et andet facade mønstre, igennem den klient der laver en instans af interfacet.
Jeg har set det beskrevet i litteraturen, at det er velegnet til at lave lag i ens design, f.eks. database lag. En facade kan så tilgå Oracle og en anden facade en SQL Server. Hvis de implementere det samme interface kan man dynamisk i runtime udskifte en facade med en anden uden problemer (klasserne i designet er dekoblet).
En yderligere fordel er, at du kan tilføje en ny facade uden at rette i den eksisterende kode. Design patterns lægger også igennem dekobling op til, at man ikke behøver at rette i eksisterende kode (med de fejl der måtte følge) men kan nøjes med at lave nye klasser, der passer ind i ens fleksible design.
Så du er på rette vej ved at lave din facade implementere et interface, og så referere det interface i den klient du skal tilgå databasen i.
>> softspot: Det gode ved et "fint" navn er, at udviklere kan snakke sammen på et højere abstraktionsniveau. Et krav til et design pattern er faktisk at det har et navn.
men jeg kan ikke se ideen med at lave en interface klasse til facaden i min applikation.
her er kort fortalt, hvordan jeg har bygget (asp.net) applikationen op:
1. jeg har en pagetemplate klasse. 2. jeg har 12-15 klasser som arver ned fra pagetemplate. alle disse klasser fungerer som code behinds for webforms. dvs der er 12-15 webforms. grunden til at alle klasserne arver ned fra pagetemplate handler om identificering af brugeren. identificering sker ved at kigge på windows logon (Request.ServerVariables[LOGON_USER]. ikke alle typer brugere har adgang til alle sider. dette ville kræve at man i alle klasserne skulle lave et database kald for at finde ud af om brugeren der er logget på må komme ind på siden.
så det har jeg løst ved at placere dette database kald (det er sef ikke et direkte database kald - det går i gennem database facaden) i OnInit metoden i pagetemplate - og da alle klasser arver ned fra pagetemplate har men hele tiden denne information "ved hånden".
3. jeg har en dbhandler klasse som fungerer som facade til databasen. denne arver sef ikke ned fra pagetemplate eller noget andet.
her er et eksempel på, hvordan jeg anvender tingene.
jeg har en class A og en class DbHandler. jeg ønsker at skrive til databasen.
public class A { DbHandler dbTest = new DbHandler(); dbTest.EnEllerAndenMetode(); }
public class DbHandler() { public void EnEllerAndenMetode() { SQL kald til selve databasen } }
er det viste eksempel en korrekt anvendelse af facade design pattern'et?
Nej. Det er overkill at kalde dit eksempel andet end en metode, der blot kalder andre metoder.
En facade pattern (et objekt) indkaplser en gruppe af objekter. Disse objekter tilgåes kun igennem facaden. Dvs. at den klient der tilgår facaden ikke kender noget til den gruppe af objekter, der ligger bag facaden.
Dit kode skelet er i og for sig fint nok, men noget tyndt at kalde det et facade patttern, som det står i eksemplet. Fyld alle de klasser ned i DbHandler som du har brug for. Fra din klasse A tilgår du så alle de klasser igennem DbHandler (kun igennem DbHandle, som metoder af objektet dbTest).
Så skulle du vist være undervejs med et fint facade pattern.
DbHandler er en klasse. Jeg skal da ikke have andre klasser ned i den eller hvad?
Alle metoder som omhandler database kald er placeret i DbHandler. Når jeg fra en af de almindelige klasser ønsker at tilgå databasen, oprettes der en ny forekomst af DbHandler klassen DbHandler dtTest = new DbHandler;
Og kun i gennem dbTest kan der tilgås metoder i DbHandler.
>>DbHandler er en klasse. Jeg skal da ikke have andre klasser ned i den eller hvad? Jo, som instans variabler.
>>Alle metoder som omhandler database kald er placeret i DbHandler Disse metoder kommer vel fra forskellige klasser, som du har instanser af i DbHandler. I dit eksempel er det ingenting der returneres af EnEllerAndenMetode.
Tænk på det som du bruger nogle klasser med metoder, der returnere noget. Du vil bare tilgå alle klasserne (og nogle af deres metoder) igennem kun een klasse. Dvs. din klient (Klasse A) tilgår kun DbHandler og ikke de andre klasser du bruger inde i maven på DbHandler.
Tænk også på at det der i princippet sker er, at du indkapsler en gruppe af objekter i et objekt. Den indkapsling sker ved at du har instanser af gruppen af objekter i dit facade objekt. Dit facade objekt returner så tilbage til klienten (Klasse A).
I dit eksempel public class DbHandler() er der ikke angivet nogle objekter. Dem der skal pakkes ind i DbHandler.
Ok jeg tror faktisk at vi er enige - det lyder meget på den måde jeg har lavet det. Det er nok mere mit hurtigskrevne dårlige eksempel der skal omskrives til noget mere brugbart:
namespace Test { public class DbHandler { private void OpenConnection() { if(myConnection.State == ConnectionState.Closed) { myConnection.Open(); } }
public int insertInTest(string strTest) { int intMaxId; myConnection = new OleDbConnection(conStr); OleDbCommand objCmd = new OleDbCommand("INSERT INTO bla bla", myConnection); OpenConnection(); objCmd.ExecuteNonQuery(); objCmd = new OleDbCommand("SELECT @@IDENTITY", myConnection); intMaxId = (int)objCmd.ExecuteScalar(); CloseConnection(); return intMaxId; } Alle andre metoder til database kald er også i DbHandler klassen. }
public class A: PageTemplate { private void Page_Load(object sender, eventargs e) { DbHandler dbTest = new DbHandler; int tal = dbTest.InsertInTest("hejsa"); } }
integeren "tal" kommer så til at indeholde id på den entry der lige er blevet indsat i databasen.
var det bedre denne gang eller er den stadig gal?
>>Disse metoder kommer vel fra forskellige klasser alle metoderne er i DbHandler klassen. jeg har en hel masse metoder inde i DbHandler som jeg kalder fra de forskellige klasser rundt omkring. men dette kan kun ske, efter at man har lavet en DbHandler dbTest = new DbHandler(); i den aktuelle klasse.
Princippet ser fint ud. Du tilgår kun metoder igennem dbTest objektet og pakker alt din db handling ind i et objekt. Det kunne man jo kalde EOOP: Ekstra Objekt Orienteret Programmering. Skal selv til at lave noget lignende.
Hvad er det jeg mangler for at det kan kaldes en facade? Har du har kigget på den højre af figurerne på figur 6.4 i det link du giver mig? For jeg gør det samme.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
