Interview question: Repository Pattern e Factory Pattern

Oggi parleremo di Repository Pattern e Factory Pattern. Entrambi fanno parte della categoria dei Design pattern ossia quell'insieme di schemi di progettazione che permettono di risolvere problemi riccorrenti. Esistono diversi tipi di pattern che sono classificati in base a diversi criteri. Solitamente si sceglie di classificare i pattern a seconda del problema che trattano.
In questo post tratteremo due pattern in particolare: il Factory Pattern e il Repository Pattern. Il Factory Pattern rientra nella categoria dei "pattern creazionali" ossia tutti quei pattern che si nascondono i costruttori delle classi "camuffandoli" con metodi in modo che si possano utilizzare gli oggetti senza sapere come siano utilizzati (un po' come fanno le interfacce). Questo pattern aiuta a modellare un interfaccia per la creazione di un oggetto il quale nel momento in cui viene creato può permettere alle sue sottoclassi di decidere quale classe instanziare.

Questo pattern, come mostrato in figura, è usato quando la classe Creato non conosce in anticipo tutte le sue sottoclassi che andrà a creare. Invce è lasciata ad ogni sottoclasse, la ConcreteCreator, la responsabilità della creazione dell'istanza dell'oggetto corrente.

Il Repository Pattern fa parte dell'insieme dei pattern architetturali che non operano a livello di design e quindi non sono considerati veri e propri pattern. Questo pattern vuole evitare l'accesso diretto alle fonti dati come database, servizi web, liste sharepoint ecc. in quanto questo comperterebbe diversi problemi come codice duplicato, alto rischio di errori di programmazione, tipizzazione debole dei dati di business e cosi via. Cosa propone questo pattern? L'utilizzo di un repository per separare la logica di ritrovamento dei dati dalla logica di bussiness.

In questo modo la logica di bussiness e il data source non comunicano direttamente ma lo fanno solo attraverso i repository come mostrato in precedenza nella figura.