6
votes

Pocos et méthodes utilitaires

suppose que j'ai une classe POCO contenant foos code> et code>: xxx pré>

dans mon exemple, j'ai besoin d'être capable Pour ajouter et supprimer foos code> et barres code>: p> xxx pré>

mais disons que j'ai aussi besoin de la contrainte (arbitraire) que Il doit y avoir un foo code> par bar code> et également une barre par code> par foo code>. p>

public class Poco {
  public IEnumerable<Foo> Foos { get { return foos; } }
  public IEnumerable<Bar> Bars { get { return bars; } }
  public PocoModifier Modifier { get { ... } }

  internal List<Foo> foos;
  internal List<Bar> bars;
}

public class PocoModifier {
  private readonly Poco toModify;
  public void Add(Foo f, Bar b) {...}
  public void Remove(Foo f, Bar b) {...}
  ...
}

c# poco

3 commentaires

Personnellement, cela ne me dérange pas d'avoir des méthodes utilitaires sur vos pocos (même s'ils ne sont plus vraiment Pocos). Une autre option consiste à créer une bibliothèque de méthodes d'extension distincte ou un pocomofinier statique externe à vos pocos (de sorte que vous n'entriez pas de cours de nidification), mais la faisabilité de cela dépend de si vous exposez votre POCO à un client.

Pour moi, il semble que vous tirez une logique commerciale dans vos entités. Écrivez la logique d'entreprise dans un calque séparé.

On se sent comme si vous avez des restrictions arbitraires que vous avez personnellement décidé de forcer votre code ... Peut-être que si vous pensez pourquoi vous le faites, vous pouvez décider de vous-même ... Note latérale: votre premier objet n'est pas vraiment immuable - Vous exposez des listes pour commencer (exigez CAST, mais qui sera arrêtée par cela) et ne pas montrer d'autres méthodes ...

3 Réponses :

12
votes

On dirait que vos données seraient mieux modélisées par quelque chose qui paires naturellement un FOO code> avec une barre code>.

public class Poco {
  public IList<Foo> Foos { get; set; }
  public IList<Bar> Bars { get; set; }
}

0 commentaires

0
votes

Je vais avec des référentiels pour gérer les pocos persistants (à l'aide de EF). Voici un exemple de référentiel générique: xxx

et c'est l'utilisation xxx

Vous ne faites pas de sorte que vous ne comprenez pas votre pocos et avez un Objet spécifiquement conçu pour persister votre POCO. Je ne suis pas un fan de référentiels génériques - était bon pour un exemple rapide. Vous pouvez créer des référentiels spécifiques à chaque entité avec des méthodes de récupération plus spécifiques.

0 commentaires

2
votes

Pocos représente uniquement une unité de données / informations. Une fois que vous avez commencé à appliquer les règles comme contrainte ou comme moyen de mieux organiser vos données, vous commencez à définir le comportement de vos données. Soudainement, vous ne traitez plus de Pocos et cela devient une structure de données pleine épouse.

Comment vous implémentez ceci est à vous. Si vous souhaitez travailler avec POCOS, vous pouvez séparer vos données et le comportement en utilisant des aides / extensions ou tout ce que vous avez envie ou que vous pouvez construire votre propre structure de données en combinant les données et son comportement dans une seule entité.

Il n'y a rien de mal à l'une d'entre elles et, tandis que certaines personnes préfèrent travailler avec des pocos, je préfère généralement travailler avec des structures de données qui encapsulate les données et son comportement dans une seule entité.

0 commentaires