Enforcing Serialization

  • Thread starter Thread starter phillipwei
  • Start date Start date
P

phillipwei

We're trying to enforce serialization of all our widely used objects
at our company (our entire company's technology team is probably about
a hundred people) and are trying to come up with a good, automated way
of doing this.

We're considering asking people to explicitly put attributes on all
public objects designating if they are/aren't serializable.

Any thoughts on this being a good/bad idea and alternative solutions?
 
Hello phillipwei,
Any thoughts on this being a good/bad idea and alternative solutions?
Click to expand...

Thoughts, yes... most importantly, I can't really imagine the architecture
that would require the majority of classes to be serializable. Maybe
that's my lack of imagination, but I assume a similar point of view is the
reason why [Serializable] follows an opt-in model.

Otherwise, if you have a guideline and you want to check that people keep
to it - why don't you combine that with your unit tests? I imagine it
would be rather easy, using some reflection maybe, to have an automated
test run for every data layer class (for instance) that would test that
class for correct application of the serialization attribute, or even
better that would actually test serialization at that point.


Oliver Sturm
 
I would say you probably want all Value Objects to be serializable and
thus it would make sense to have standards such as "all solutions must
have a project specifically for value objects named
solution.ValueObjects" and "all value objects must be serializable"
and then you can have standard unit tests that can find all value
object projects within all solutions (assuming a well defined
hierarchy within source control) and enforce these standards.

HTH,

Sam
 
Back
Top