Utilisation du référentiel entre le modèle EF et le consommateur de code

Question

J'ai des données binaires dans ma base de données que je vais devoir convertir en bitmap à un moment donné. Je pensais s'il était approprié ou non d'utiliser un référentiel et de le faire ici. Mon client, qui est une couche de présentation, utilisera ce référentiel. Par exemple:

// This is a class I created for modeling the item as is. 
public class RealItem 
{ 
    public string Name { get; set; } 
    public Bitmap Image { get; set; } 
} 

public abstract class BaseRepository 
{ 
    //using Unity (http://unity.codeplex.com) to inject the dependancy of entity context. 
    [Dependency] 
    public Context { get; set; } 
} 

public calss ItemRepository : BaseRepository 
{ 
    public List<Items> Select() 
    { 
     IEnumerable<Items> items = from item in Context.Items select item; 
     List<RealItem> lst = new List<RealItem>(); 
     foreach(itm in items) 
     { 
      MemoryStream stream = new MemoryStream(itm.Image); 
      Bitmap image = (Bitmap)Image.FromStream(stream); 
      RealItem ritem = new RealItem{ Name=item.Name, Image=image }; 
      lst.Add(ritem); 
     } 

     return lst; 
    } 
} 

Est-ce une façon correcte d'utiliser le modèle de référentiel? J'apprends ce modèle et je l'ai vu beaucoup d'exemples en ligne qui utilisent un référentiel, mais quand je regardais leur code source ... par exemple:

public IQueryable<object> Select 
{ 
    return from q in base.Context.MyItems select q; 
} 

comme vous pouvez le voir presque pas de comportement est ajouté au système par leur approche, sauf pour cacher la requête d'accès aux données, donc j'ai été confus que peut-être référentiel est quelque chose d'autre et j'ai tout faux. À la fin, il devrait y avoir des avantages supplémentaires de les utiliser correctement?

Mise à jour: comme il s'est avéré que vous n'avez pas besoin de dépôts s'il n'y a plus rien à faire sur les données avant de les envoyer, mais attendez! pas d'abstraction sur la requête LINQ? De cette façon, le client doit fournir pour nous les instructions de requête qui peuvent être un peu dangereuses et difficiles à valider, alors peut-être que le référentiel fournit également une abstraction sur les requêtes de données? si cela est vrai, avoir un référentiel est toujours un besoin essentiel dans l'architecture du projet !! cependant cette abstraction peut être fournie en utilisant des procédures stockées SQL. Quel est le choix si les deux options sont disponibles?

Answer 1

Oui, c'est la bonne façon: le contrat de référentiel répond aux besoins de l'application, ne traitant que des objets de l'application. L'exemple (mauvais) que vous voyez la plupart du temps associe une implémentation de référentiel à IQueryable qui peut ou non être implémentée par l'orm sous-jacent et après tout c'est un détail d'implémentation. La différence entre IQueryable et IEnumerable est importante lorsqu'il s'agit de données distantes, mais c'est ce que le référentiel fait en premier lieu: il cache le fait que vous avez affaire à un stockage qui peut être distant. Pour l'application, le référentiel est juste une collection locale d'objets.

Mise à jour Le référentiel abstrait l'accès de persistance, il rend l'application découplé d'une mise en œuvre de persistance particulière et se masque comme une collection simple. Cela signifie que l'application ne connaît pas Linq2Sql, Sql ou le type de SGBDR utilisé, le cas échéant. L'application envoie/reçoit des objets à partir du repo, tandis que le repo persiste ou charge des objets. L'application ne se soucie pas comment le repo le fait. Je considère le référentiel comme un modèle très utile et je l'utilise dans tous les projets, précisément parce qu'il marque la limite entre l'application (où les problèmes et les solutions sont définis et traités) et le stockage/la persistance où les données est enregistré.

Answer 2

Vous pouvez faire de votre dépôt un générique et en extraire la valeur de mode. Et assurez-vous que vous utilisez une interface (IItemRepository) pour accéder aux référentiels dans la couche du gestionnaire afin que vous puissiez remplacer vos référentiels par une autre méthode d'accès aux données en utilisant la nouvelle implémentation du référentiel. Here is an good exampl e comment faire ceci.