.NET Architecture – Why All Classes Inherit from Object

I haven't worked much with MVC, however I have worked a lot with MVVM and here's my take on it:

Question, Answer, and User are all data objects. Its OK for them to know of each other, but they should not be aware of anything outside of the data object layer, such as Views, Controllers, ViewModels, etc.

In an ideal world, your View only references the Models. They might know of the Controller, but they shouldn't have to reference it directly. The ViewModel only knows of other Models. The Controller knows about Models and ViewModels. It doesn't care about the View at all, even though it supplies the View with ViewModels or Models.

So your objects end up looking like this:

• M odels come in two varieties: Models and ViewModels.

  • Models are simple data objects that simply exist to hold data, and are generally a reflection of database data. They do not access the database or contain any sort of business logic that is unrelated to them.
  • ViewModels are data objects that contain data that the View needs, not necessarily what the database needs. They can contain Models, although Models should not contain ViewModels.

• C ontrollers contain your business logic. They control the data access calls, creating Models/ViewModels to pass to the View, advanced business logic such as permissions, etc. They basically control the entire code layer.

• V iews are just used to give the users a user-friendly interface. They accept either a ViewModel or Model, and display it in some way that looks nice to the user.

The real question is: WHY does the architect want everything to inherit from base? What's the utility of doing so?

If it's for something like serialization interfaces, then it MIGHT make sense if you will need a general serialization facility. But make sure that you actually will need EVERY class in the system to have that functionality. If you don't, then you end up needlessly inflating each class, AND you'll end up having to implement (or stub out) functionality in classes where that functionality doesn't make sense.

I would NEVER implement my own 'uber-base' like this in a system, because I can't conceive of any functionality or interface that I would want in EVERY object EVERYWHERE in my system. The only thing I can think of that it might be useful for is something like heterogeneous containers, but I've never been in a situation where I wanted a completely heterogeneous container - I generally want a set of classes, not just any random thing under the sun to go into my containers.

Unless the architect can demonstrate why they want this uber-base, I'd leave it out.