Toepassing OO principe DRY

[martijngr85]

Goedemorgen,

Ik heb wat moeite met het principe Don't Repeat Yourself. Ik heb vele methods waarvan de implementatie veel op elkaar lijken. Een voorbeeld (C#):

C#:

Database db = new Database; // mijn eigen database class
string query = "SELECT * FROM tabel";
SqlCommand com = new SqlCommand(query);

try
{
  if(db.ExecuteSelectQuery(com))
  {
    DataTable dt = db.GetDataTable;

    List<User> users = new List<User>();

    foreach(DataRow row in dt.Rows)
    {
      User user = new User();

       user.name = row["naam"];
       user.id = row["id"];

       users.add(user);
    }

    return users;
  }

  return null;
}
catch(Exception)
{
  throw;
}

Bovenstaand is enkel even een simpel voorbeeld. Het punt is namelijk dat ik een hoop van zulk soort methods heb, In elke method wordt een instantie van de Database class gemaakt, een SqlCommand object gemaakt en hier de bijhorende query meegegeven. En indien nodig worden bij het SqlCommand object ook de SqlParameters opgegeven. Het idee van deze method is dus steeds hetzelfde. Ik heb het gevoel dat dingen dubbel zit te doen en dat dit eenvoudiger kan, alleen heb ik nog niks kunnen verzinnen. Daarom eigenlijk mijn vraag, hebben jullie een idee om dit te vereenvoudigen? Hoe pakken jullie dit soort dingen aan?

Bedankt alvast,

Martijn.

[Voutloos]

Maak een db abstractie laag welke enkel de resultset teruggeeft? Scheelt de helft van de saaie code en is met andere db's of debugging ook wel erg leuk.

[martijngr85]

Je bedoeld dat de method een DataTable of DataSet retourneert (of null)? En waarom abstract?

[Voutloos]

abstracte laag != abstract class.

Mag van mij ook 1 op 1 op je specifieke DBMS gericht zijn, maar in theorie zou je op tot dat punt op een dbms onafhankelijke manier kunnne kletsen.

[martijngr85]

Sorry, maar ik ik volg je niet helemaal. Begrijp niet wat je bedoeld.

[RobIII]

Wat je denk ik nog veel beter kunt doen is kijken naar een O/R mapper als LLBLGen of NHibernate ofzo Scheelt een boel werk.

[ Voor 10% gewijzigd door RobIII op 01-07-2009 11:00 ]

[martijngr85]

Geen flauw idee wat dat is/zijn. Ik ben even google'en...

[muksie]

Hij bedoelt waarschijnlijk dat je een 'laag' om je database heen maakt, die alle veel gebruikte code bevat. Je hebt nu je eigen Database klasse, en dat je deze bijvoorbeeld uitbreidt met een methode executeSelect, zodat je iets kunt doen als:

code:

rows = db.executeSelect("SELECT * FROM tabel");
List<User> users = new List<User>();
foreach ...

Dan hoef je niet altijd weer de SqlCommand etc. aan te maken. Je kunt dit nog veel verder invoeren. Je zou bijvoorbeeld een functie kunnen schrijven die een rij uit de tabel omzet in een User object, en deze functie in de body van de foreach loop aan roepen. Of je maakt een UsersTable klasse aan, welke al automatisch de User objecten returned.

[CodeCaster]

muksie schreef op woensdag 01 juli 2009 @ 11:06:
Dan hoef je niet altijd weer de SqlCommand etc. aan te maken. Je kunt dit nog veel verder invoeren. Je zou bijvoorbeeld een functie kunnen schrijven die een rij uit de tabel omzet in een User object, en deze functie in de body van de foreach loop aan roepen. Of je maakt een UsersTable klasse aan, welke al automatisch de User objecten returned.

... of je gebruikt gewoon NHibernate, dat doet al het bovenstaande al voor je.

[martijngr85]

Iedereen gebruikt hier dus NHibernate?

[Janoz]

Toen ik nog geen O/R mapper gebruikte was ik erg gecharmeerd van het jdbcTemplate van Spring. Deze gaf niet een resultset terug, maar had een mapper nodig die elke row van de resultset omzette naar je domein object (of wat je er ook maar mee wilde doen). Het voordeel is dat niet alleen het aanmaken van de resultset in een aparte class zit, maar ook het uitlezen, weer opruimen en de volledige foutafhandeling van fouten die daarbij op kunnen treden.

Hier wordt vanalles over het jdbcTemplate verteld. Het lijkt me niet lastig om een dergelijke sttructuur ook voor .Net op te kunnen zetten.

[RobIII]

martijngr85 schreef op woensdag 01 juli 2009 @ 11:26:
Iedereen gebruikt hier dus NHibernate?

Natuurlijk niet; het is niet alsof er maar 1 keus is ofzo. Er zijn er wel veel die NHibernate gebruiken hier, maar "iedereen" dus niet; daarbij dien je voor jezelf de keuze te (kunnen) maken welke voor jou het best is.

[GSteven]

Indien je geen NHibernate of iets dergelijks wenst te gebruiken raadt ik zeker en vast aan om het Template Method pattern toe te passen.

Een zeer mooi voorbeeld hiervan komt van Janoz met die jdbcTemplate.

[whoami]

RobIII schreef op woensdag 01 juli 2009 @ 11:32:
[...]

Natuurlijk niet; het is niet alsof er maar 1 keus is ofzo. Er zijn er wel veel die NHibernate gebruiken hier, maar "iedereen" dus niet; daarbij dien je voor jezelf de keuze te (kunnen) maken welke voor jou het best is.

Niet ?


Wat ik niet snap, is dat je een 'Database' class hebt gemaakt, maar dat je nog eens apart (daarbuiten) je IDbCommand objecten etc.. moet gaan maken / aanspreken.
Als ik een database-class zie, zou ik toch verwachten dat dit ge-abstraheerd werd.