In .NET Application Architecture Guide, 2nd Edition, the writers explicitly say:
Do not mix different types of components in the same logical layer. Start by identifying different areas of concern, and then group components associated with each area of concern into logical layers. For example, the UI layer should not contain business processing components, but instead should contain components used to handle user input and process user requests.<div> </div>
This is the standard way of developing today. However, I’ve seen time and again where a developer will do ALL of the business logic processing in the presentation layer. More than merely being annoying, this is wrong for a number of reasons including:
- redundancy in code
- “scattered” logic
- poor abstraction
- data access in the presentation layer
- strong-coupling
<div>
That’s just to name a few. Every time I see this coding snafu occur, I think to myself, “Do I just not know what I’m doing?” After all, it’s much more seasoned developers doing this. Then, I remind myself that object-oriented programming has changed dramatically over the past 10 years.
</div>
<div>
</div>
<div>
I can understand some points of view “Too much abstraction is a bad thing!”, “Keep the logic as close to where you’re using it as possible!”, “I don’t understand what you mean by <i>business logic.</i>” But, ignorance of norms and coding standards doesn’t inherently and automagically produce good, clean, scalable code.
</div>
<div>
</div>
<div>
N-tier architecture has now become the norm, but is it too much to ask for some logical layering within a tier?
</div>