If a class has no logic, then that would be considered a data-structure. For the question about whether to use a generic collection vs a type, I would choose creating types because of their expressiveness.
Take the following example.
var employee = new Dictionary<string, object>();
employee["FirstName"] = "Steve";
employee["LastName"] = "McQueen";
employee["DOB"] = new DateTime(1942, 1, 5);
employee["Salary"] = 215000m;
Here you have the problem of
- being Stringly Typed
- unable to implement logic within the "employee"
- no possibility of being immutable
- not being able to refactor
Contrast this with.
var employee = new Employee {
FirstName = "Steve",
LastName = "McQueen",
DOB = new DateTime(1942, 1, 5),
Salary = 215000m
};
You get the benefit of
- being able to find references of employee
- subclass employee
- refactor employee (rename
DOB
toDateOfBirth
without having to do a search and replace) - make properties immutable
- compile time checking
- add domain logic if ever needed
- can impose invariants
Though the one downside to this is that you have to define a class, which means more typing, though I feel the benefits greatly outweigh the costs.
To elaborate on my examples above, suppose you wrote a method from a repository that returned an employee.
var employee = employeeRepository.GetById(25);
If employee
were a dictionary in this example, I would have no Intellisense to know which attributes an employee has, let alone their types, this is also illustrated by @HighCore's comment. The only ways to determine this is to either
- read the documentation (probably out-of-date or inaccurate)
- execute the method and inspect with debugger (a waste of time and might not be possible in every scenario)
In the scenario of persisting a new employee
, the dictionary runs into the same pitfalls and now you're at the peril of hoping the method you just executed returns meaningful error messages.