CODEWITHSUNDEEP
design-patternsmodel-view-controllerarchitecture3-tier
user3007194
user3007194

Reputation: 111

Does anyone use plain old 3 tier architecture?

So I've been learning about architectural styles and patterns. From what I can see, when it comes to 3-tier architecture, most people are using a pattern (such as MVC for example). But my question is, does anyone just use a plain old 3-tiered, bi-directional architecture without any patterns? Is that practiced or even acceptable in industry?

Upvotes: 1

Views: 1302

Answers (3)

ekostadinov
ekostadinov

Reputation: 6940

The Architecture should

Form Consistent

layers, as described in the Code Complete, 2nd Edition. Having just any of the architectural patterns and styles (MVC is actually a part of the Multitier architecture's Business tier) won't be enough. Depending from the requirements this

plain old 3-tiered bi-directional architecture

could be the best fit for a Client-server distributed system. Remember - Overdesign is bad as much as no design at all.

So as a bottom line - keeping the good practices, SOLID principles and design patterns at all levels, is what makes the good software.

design levels

Upvotes: 3

Matt Kocaj
Matt Kocaj

Reputation: 11535

Probably not so much as previously if you're referring to the generalisation most devs make when using the term "3 tier architecture".

What does that mean?

Well, in my experience, "3 tier architecture" has a connotation which invokes a generalisation around using a system design roughly broken into 3 major abstractions (or 'layers'/tiers):

  • A "UI" layer
  • A "business layer" / domain layer
  • And a database/persistence/storage layer

The problem simply is that this structure is not well defined beyond that and so most folks I know would hesitate to describe their system design this way. It's far too subjective what this means so it's open to misintrepretation.

In many simple cases some of these abstractions may not be necessary. Various persistence patterns (eg. Table Gateway) and ORM libraries out there today make it very easy to store and hydrate data in an "object friendly" way meaning that calling your code which encapsulates this work a whole "layer" might be overreaching a little.

Additionally, simple CRUD applications may have very little "business logic" at all and since the ORM facilitates CRUD happily in many cases, there isn't any business-specific logic to speak of, thus rendering this part of the system as a "layer" fairly redundant also.

The User Interface is possibly the only "layer" of these three that really stands on it's on IMO in almost all cases.

If a system has complex business/domain logic then perhaps Domain Model or other DDD patterns come into play. In complex systems a solid ORM tool is usually employed making light work of the data interfacing. Still, colleagues of mine wouldn't usually call these elements "layers" generally - they'd be more specific and name the design patterns explicitly so that the interpretation is less subjective. We certainly wouldn't be using a term like "3 tier architecture".

HTH

Upvotes: 1

user5151179
user5151179

Reputation: 585

Plain old 3-tier architecture is a pattern.

Upvotes: 0

Related Questions