Using static classes to define methods for handling POCO class objects

Question

I am pretty new to the OOP paradigm and for this current project of mine, I need to design and develop a web application backend in .NET MVC using C#.

A friend of mine told me that the class objects we use mostly for passing information from one layer/function to other should be as small as possible, which is a sound argument and hence I also presumed that we better not have methods in this class and store only properties. This requires me to define another class that would have some methods defined solely to do operations on this class's objects.

I was wondering if making this whole method-only class a static class is good option or not? Or may be make these methods a part of the property-only class but make them static.

Am I thinking on the right track? Are there any cons of using static which I should be aware of? Any costs associated with it?

Answer 1

"Static" is sometimes a naughty word in the C# world, because it makes it difficult to create Unit Tests around the class in question, unless the class is doing nothing but logic-processing and has no database, file I/O operations, or any such behavior. If you're passing data or commands from layer to layer, then I would suggest that your class NOT be static.

Did your friend specify WHY your data classes should be small? I suspect its not because of memory size, but rather because its best to break those data classes down to be as small and specific as you need, and not any larger. When you first get into OOP, there's a tendency to create "God" classes that have dozens of methods and fields. This feels "right" at first ("Oh look, I've got everything I need in one class/spot, great!") but it quickly bogs down into an unmaintainable mess.

A common pattern that I like to use is having my data transfer object (or POCOS, they have diff names) be very small and very dumb. Just structures really (but not the "struct" keyword, that's a whole 'nother ball of wax), with no methods or behavior of any sort. Having properties that do very basic null checking, string building, and/or aggregation on other fields of the same class is fine, but any bigger behavior goes elsewhere. The class that actually does work (database, file stuff) is a separate class with a bunch of methods that take these data transfer objects as params, or return them as results. This "data access provider" class won't have very many properties itself, and usually implements an interface (keyword: "interface" in C#) that I define that requires those methods.

The point of the interface is so my web apps or whatever can just call that class through the interface, and I can hot-swap in a different class that satisfies the interface that might just drop in dummy data, for testing purposes. You can't do that type of thing if the data access class is static.

Summary: If you truly want your data access class to ONLY behave in one way (actually trigger sql calls or file i/o and not be "mockable") then your data access class can be static, but I'd recommend against it. You'll be boxing yourself into a corner later, if you get into Unit/Integration Testing. (However, it wouldn't be terribly difficult to refactor at that point honestly)

Answer 2

A method on a class in c# doesnt actually take any memory on an actual instance of the class. So every object you create of this class will still be the same size whether or not you added some extra methods to the class. You definitely should not create a new class to do these operations that are closely bound to your 'data-passing-class'.