Il modello del repository è uguale al modello del provider Asp.net?

Question

Da Asp.net 2.0, esiste il modello del provider. Per quanto riguarda i dettagli dell'implementazione, un provider è una classe derivata da ProviderBase che è una classe astratta piuttosto che un'interfaccia, ma comunque il Modello del provider è lì in modo che possiamo avere un'implementazione diversa da scambiare in entrata semplicemente modificando web.config. Ad esempio, se crei un'app blog, potresti avere un BlogProvider: ProviderBase, quindi puoi avere implementazioni di BlogProvider come: SqlBlogProvider, OracleBlogProvider e persino MockBlogProvider per i test.

Ora, il Repository Pattern sta diventando popolare, e penso che sia per soddisfare la stessa necessità, anche se nei dettagli dell'implementazione normalmente usi interfacce, quindi IBlogProvider, e inietteresti implementazioni diverse attraverso i costruttori piuttosto che le proprietà, ma essenzialmente non vedo la differenza in ciò che ci hanno dato questi 2 schemi.

Personalmente, ritengo che il modello del provider sia più naturale per me nell'implementazione. Quindi, c'è una differenza tra loro o sono esattamente la stessa cosa con nomi diversi dati da comunità diverse?

Gradirei eventuali commenti al riguardo, Grazie, Ray.

Answer 1

I modelli di repository e provider si sovrappongono, ma non descrivono formalmente la stessa cosa. Direi quasi che il repository è un sottoinsieme di Provider. In pratica, penso che il modello del repository fosse nato da un'esigenza specifica - astrarre i repository - e si sia evoluto nella comunità in un modello di astrazione più generico. A tale proposito, sono diventati termini diversi che descrivono lo stesso concetto. Tuttavia, dalle definizioni originali, hanno un ambito diverso:

• Lo scopo del modello di repository è quello di sottrarre le specifiche di un repository di dati lontano dall'applicazione.

• Lo scopo del modello del provider è di estrarre le specifiche di qualsiasi cosa dall'applicazione. Questo può essere un repository di dati, ma è altrettanto spesso una sorta di logica.

Ad esempio, nella nostra applicazione abbiamo un ContextFactoryProvider, che contiene diversi tipi di logica per determinare quale ContextFactory utilizzare. Non esiste un repository di dati in questo caso; è una logica puramente applicativa che deve cambiare arbitrariamente; il modello del provider ci consente di utilizzare il Principio di responsabilità unico per isolare ogni tipo di logica nella sua classe e scambia facilmente quella logica.

Answer 2

Non posso essere d'accordo con Rex M. Lo scopo del pattern provider è di fornire supporto per la personalizzazione tramite un'interfaccia astratta, dove lo scopo del pattern repository è di fornire un supporto per astrarre i dettagli del database indebitamente.