POCOs and Utilities

Question

Suppose I have a POCO class containing foos and bars :

 public class Poco { public IEnumerable<Foo> Foos { get { return foos; } } public IEnumerable<Bar> Bars { get { return bars; } } private List<Foo> foos; private List<Bar> bars; } 

In my example, I need to be able to add and remove foos and bars :

 public class Poco { public IList<Foo> Foos { get { return foos; } } public IList<Bar> Bars { get { return bars; } } private List<Foo> foos; private List<Bar> bars; } 

But let's say that I also need a (arbitrary) restriction that there must be one foo per bar , and also one bar per foo .

 public class NotAPocoAnyMore { public IEnumerable<Foo> Foos { get { return foos; } } public IEnumerable<Bar> Bars { get { return bars; } } private List<Foo> foos; private List<Bar> bars; public void Add(Foo f, Bar b) {...} public void Remove(Foo f, Bar b) {...} } 

My question is this: am I getting ready to try to keep POCO simple and not give it any useful methods? The first example of POCO is good because it is immutable, and POCOs have other advantages. However, I see no way to preserve the POCO class and still have ways to access and modify the contents in a controlled way (at least not as if it weren’t too hard to kill).

Some thought I had:

Nested Modifier Class

 public class Poco { public IEnumerable<Foo> Foos { get { return foos; } } public IEnumerable<Bar> Bars { get { return bars; } } public PocoModifier Modifier { get { ... } } private List<Foo> foos; private List<Bar> bars; public class PocoModifier { private readonly Poco toModify; public void Add(Foo f, Bar b) {...} public void Remove(Foo f, Bar b) {...} ... } } 

Open nested class? No thanks! In addition, it is really the same as the non-POCO class, with a little nesting.

Using Access Modifiers

 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) {...} ... } 

Slightly better, but each POCO requires a whole deployment unit.

Answer 1

It looks like your data will be better modeled by something that naturally combines Foo with Bar .

 public class Poco { public IList<Tuple<Foo, Bar>> FooBars { get { return fooBars; } } private List<Tuple<Foo, Bar>> fooBars; } 

If for some strange reason, Foo and Bar completely separate, except for the requirement that their number be the same. Then I like your third example ...

 public class NotAPocoAnyMore { public IEnumerable<Foo> Foos { get { return foos; } } public IEnumerable<Bar> Bars { get { return bars; } } private List<Foo> foos; private List<Bar> bars; public void Add(Foo f, Bar b) {...} public void Remove(Foo f, Bar b) {...} } 

PocoModifier adds unnecessary complexity in my opinion. And nested classes should not be publicly available at all (therefore, if you have a class at all, make it separate, as in your last example).

If you also need POCO (for example, publish it publicly for people using your code as a library while maintaining internal internal logic), you can create a simple POCO and then map it to NotAPocoAnyMore using AutoMapper (or similar).

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

Answer 2

POCOs are only a unit of data / information. Once you start applying the rules as a restriction or as a way to better organize your data, you begin to determine the behavior of your data. Suddenly you are no longer dealing with POCOs and becoming a full-sized data structure.

How you implement this is up to you. If you want to work with POCOs, you can separate your data and behavior using Helpers / Extensions or whatever you like, or you can create your own data structure by combining data and their behavior in one object.

There is nothing wrong with any of them, and although some people prefer working with POCOs, I usually prefer working with Data Structures, which encapsulates data and their behavior in a single object.

Answer 3

I go with repositories to handle persistent POCOs (using EF). The following is an example of a shared repository:

 public interface IRepository<T> { void Add(T entity); void Remove(T entity); ... } public class Repository<T> : IRepository<T> { // dbset or list or whatever you're persisting to public void Add(T entity) { // add to dbSet } public void Remove(T entity) { // remove from dbSet } } 

And this use

 var repo = new Repository<User>(); repo.Add(new User()); 

Now you do not mutate your POCOs and do not have an object specifically designed to save your POCO. I am not a fan of generic repositories - this was good for a quick example. You can make repositories specific to each object with more specific search methods.