[C#] Database toegang met het strategy pattern

[martijngr85]

Ik ben nieuw met design patterns en heb nu het strategy toegepast. Dit is opzich aardig gelukt, alleen nu vraag ik ma af hoe ik de database toegang moet implementeren. Dit is wat ik nu heb:

code:

    namespace StrategyPattern
    {
        public interface ISendBehavior
        {
            void Send();
        }

        public class SendAppointment : ISendBehavior
        {
            public void Send()
            {
                // implement code
            }
        }

        public class SendTask : ISendBehavior
        {
            public void Send()
            {
                // send item
            }
        }

        public class SendItem
        {
            ISendBehavior _sendBehavior;

            public SendItem(ISendBehavior sendbehavior)
            {
                _sendBehavior = sendbehavior;
            }

            public void Send()
            {
                _sendBehavior.Send();
            }
        }

        /* AANROEP */

        public class Aanroep
        {
            public void Verzenden()
            {
                SendItem app = new SendItem(new SendAppointment());
                app.Send();
            }
            
        }
    }

Waar ik nu mee zit is het volgende. De classes die ISendBehavior hebben geerfd hebben dus de methode Send(). Is het nu wijs om in elke class die van ISendBehavior erft een database instantie te maken? Om dan vervolgens de query op te zetten en ander database gerelateerde zaken af te handelen?

[D-Raven]

Euh nee. Het lijkt me dat je een aparte laag wilt hebben welke je DAL symboliseert welke dat regelt.
SendAppointment lijkt mij meer een business object waarin je een bepaalde taak uitvoert (het versturen van een afspraak ofzo?). Dat kan naast het aanroepen van je DAL ook andere dingen zijn (email versturen misschien).

Kortom het is niet wijs om in elke implementatie van je interface apart een database instantie op te bouwen. Sterker nog, dat wil je daar helemaal niet doen.

[Verwijderd]

Je moet je wel afvragen of een dergelijk pattern geschikt is voor wat je wil doen, anders kun je het net zo goed niet doen. Waar je strategy voor gebruikt is het dynamisch maken van gedrag @ runtime door het gebruik van interfaces. Zomaar een voorbeeld: je maakt een spel met een poppetje dat kan schieten, met strategy kun je er voor zorgen dat je poppetje eenvoudig kan gaan steken met een mes.
Voor database toegang heb je andere patterns, die je, uiteraard, wel kan combineren voor verschillende toepassingen. Je zou eens hier: http://www.objectarchitects.de/ObjectArchitects/orpatterns/ kunnen kijken om wat kennis op te doen voor data-access patterns en gerelateerde zaken (vrij complexe materie).

[EfBe]

Patterns zijn oplossingen voor gedefinieerde problemen. Dus eerst probleem herkennen, dan kijken of er een oplossing voor is in de vorm van een pattern, en dan het pattern toepassen. de andere kant op, dus eerst pattern pakken en dat dan implementeren zonder te kijken of je uberhaupt het probleem hebt wat het pattern oplost is _dom_. Het maakt namelijk je code onnodig ingewikkeld.

[Verwijderd]

Bedankt voor de reacties.

@deathraven: Jij stelt dus voor om in SendAppointment een gevuld object mee te geven dat (inderdaad) verzonden moet worden als afspraak? En het vullen van dit object vindt ergens anders plaats.