Return to Answer

OOD fits inside the layers.

Multitier or N-layer architecture is the fancy grown up version of MVC. The big thing they have in common is separated areas of focus. Here, they're called layers (or tiers). That separation creates a boundary. And boundaries present a challenge to OOD.

One of the hallmarks of OOD (that's Object Oriented Design not Ood) is that methods are moved to live with the data (or state) that they know how to act on. Doing this allows encapsulation, abstraction, and can actually be faster since you aren't moving data around.

However, sometimes a method ends up on the other side of a boundary from it's data. This is where OOD breaks down. You can't put the method where the data is. Either because you’re trying to keep your layer (tier) focused on it's responsibility or you simply don't own that code.

So at that point you give up and move the data. It's not purely OOD. It's just how we get it done.

But inside that layer you aren't faced with that boundary and can pair methods with their data to your little OOD hearts content.

Almost all software is full of compromised ideals. Don't chase perfection. Just carve out little places where the ideals can help.

OOD fits inside the layers.

Multitier or N-layer architecture is the fancy grown up version of MVC. The big thing they have in common is separated areas of focus. Here, they're called layers (or tiers). That separation creates a boundary. And boundaries present a challenge to OOD.

One of the hallmarks of OOD (that's Object Oriented Design not Ood) is that methods are moved to live with the data (or state) that they know how to act on. Doing this allows encapsulation, abstraction, and can actually be faster since you aren't moving data around.

However, sometimes a method ends up on the other side of a boundary from it's data. This is where OOD breaks down. You can't put the method where the data is. Either because you’re trying to keep your layer (tier) focused on it's responsibility or you simply don't own that code.

So at that point you give up and move the data. It's not purely OOD. It's just how we get it done.

But inside that layer you aren't faced with that boundary and can pair methods with their data to your little OOD lovin` hearts content.

Almost all software is full of compromised ideals. Don't chase perfection. Just carve out little places where the ideals can help.

OOD fits inside the layers.

Multitier or N-layer architecture is the fancy grown up version of MVC. The big thing they have in common is separated areas of focus. Here, they're called layers (or tiers). That separation creates a boundary. And boundaries present a challenge to OOD.

One of the hallmarks of OOD (that's Object Oriented Design not Ood) is that methods are moved to live with the data (or state) that they know how to act on. Doing this allows encapsulation, abstraction, and can actually be faster since you aren't moving data around.

However, sometimes a method ends up on the other side of a boundary from it's data. This is where OOD breaks down. You can't put the method where the data is. Either because your trying to keep your layer (tier) focused on it's responsibility or you simply don't own that code.

So at that point you give up and move the data. It's not purely OOD. It's just how we get it done.

But inside that layer you aren't faced with that boundary and can pair methods with their data to your little OOD hearts content.

Almost all software is full of compromised ideals. Don't chase perfection. Just carve out little places where the ideals can help.

OOD fits inside the layers.

Multitier or N-layer architecture is the fancy grown up version of MVC. The big thing they have in common is separated areas of focus. Here, they're called layers (or tiers). That separation creates a boundary. And boundaries present a challenge to OOD.

One of the hallmarks of OOD (that's Object Oriented Design not Ood) is that methods are moved to live with the data (or state) that they know how to act on. Doing this allows encapsulation, abstraction, and can actually be faster since you aren't moving data around.

However, sometimes a method ends up on the other side of a boundary from it's data. This is where OOD breaks down. You can't put the method where the data is. Either because you’re trying to keep your layer (tier) focused on it's responsibility or you simply don't own that code.

So at that point you give up and move the data. It's not purely OOD. It's just how we get it done.

But inside that layer you aren't faced with that boundary and can pair methods with their data to your little OOD hearts content.

Almost all software is full of compromised ideals. Don't chase perfection. Just carve out little places where the ideals can help.

OOD fits inside the layers.

Multitier or N-layer architecture is the fancy grown up version of MVC. The big thing they have in common is separated areas of focus. Here, they're called layers (or tiers). That separation creates a boundary. And boundaries present a challenge to OOD.

One of the hallmarks of OOD (that's Object Oriented Design not Ood) is methods are moved to live with the data (or state) that they know how to act on. Doing this allows encapsulation, abstraction, and can actually be faster since you aren't moving data around.

However, sometimes a method ends up on the other side of a boundary from it's data. This is where OOD breaks down. You can't put the method where the data is. Either because your trying to keep your layer (tier) focused on it's responsibility or you simply don't own that code.

So at that point you give up and move the data. It's not purely OOD. It's just how we get it done.

Almost all software is full of compromised ideals. Don't chase perfection. Just carve out little places where the ideals can help.

OOD fits inside the layers.

Multitier or N-layer architecture is the fancy grown up version of MVC. The big thing they have in common is separated areas of focus. Here, they're called layers (or tiers). That separation creates a boundary. And boundaries present a challenge to OOD.

One of the hallmarks of OOD (that's Object Oriented Design not Ood) is that methods are moved to live with the data (or state) that they know how to act on. Doing this allows encapsulation, abstraction, and can actually be faster since you aren't moving data around.

However, sometimes a method ends up on the other side of a boundary from it's data. This is where OOD breaks down. You can't put the method where the data is. Either because your trying to keep your layer (tier) focused on it's responsibility or you simply don't own that code.

So at that point you give up and move the data. It's not purely OOD. It's just how we get it done.

But inside that layer you aren't faced with that boundary and can pair methods with their data to your little OOD hearts content.

Almost all software is full of compromised ideals. Don't chase perfection. Just carve out little places where the ideals can help.