I'm in the camp that loves OO. I want smart objects for
everything. I don't like data-centric programming. I don't
like thowing raw data around in DataSets. I create custom objects
for everything in my applications. I was reflecting on a very
simple application, and I realized that every application has a natural
domain model. I've had conversations where a developer has said,
"Our application is different. It's not an enterprise
application. Domain-driven design doesn't apply." I've come
up with a really simple example to illustrate my point.
Suppose you have an application that only maintains social security
numbers. That's it. It doesn't store person information, just
social security numbers. In fact, your entire database is one
table with one char(9) field. One might just go ahead and
keep the social security numbers in a string. Would that
work? Yes, but consider the natural domain object for this:
public class SocialSecurityNumber
{
private string _rawNumber;
public SocialSecurityNumber(string number)
{
_rawNumber = number;
}
public string GetWithoutDashes()
{
return; //the ssn without dashes.
}
public override string ToString()
{
//format ssn nicely and output.
return; //the nice output.
}
public override bool Equals(object obj)
{
return true; //or false if they don't match.
//Use some intelligence to compare for sameness.
}
}
You could store the information in a string, but then that is a magic
string floating around your application, and every class _just_ has to
know that it must be a social security number. There is no strong
typing to enforce that there are exactly 9 numerals in the
string. What about dashes? with this SocialSecurityNumber
class, you have your domain model, and now you can enforce all the
rules about the number easily. Maybe you want to always store it
in the database without dashes but want to display it on the UI with
dashes. Instead of string manipulation elsewhere, encapsulate
that logic directly inside the domain object. If you use this
object throughout your system, it's clear that constraints will always
be enforced, and you never have double check that a social security
number is really there - the compiler picks up that burden for you as
well as runtime strong type checking.
Consider your current applications. Do you have a prominent
string, bool, or int? Would it be helpful if that piece of
information could carry around describing and validating
information? Consider creating a domain object to house that
single piece of information and enforce rules about it. I think
it'll make the application a lot simpler.