3-tier architecture dependencies

3
votes

I've been struggling with how to structure my 3-tier applications. I always seem to end up with dependency issues that I don't want, which is a sure sign that i'm doing something wrong.

How do you typically structure your 3-tier architecture?

I see one of 2 ways to do this:

  1. Business tier is at the top (or bottom, depending on how you look at it) ad all other layers depend on it. The business layer defines interfaces it needs to do its job, particularly for data access. The data access layer implements those interfaces, and Dependency Injection is used to inject them into the middle tier. The UI likewise consumes the output interfaces, again through DI. Business objects are POCO's that the Data layer fills. Data layer does not have it's own code model (it uses the business objects defined in the business layer). Business layer knows nothing about either UI or Data layer, UI and Data Layer know about business layer.
  2. UI Tier is at the top, Business in the middle, Data at the bottom. The Data layer publishes interfaces that the Business tier consumes. Business has interfaces that the UI consumes. It's a straight 1-2-3 sort of situation. Data Layer defines code objects, business layer has it's own model (and something like AutoMapper is used to map between them. But this mapping is performed in the business layer). Data Layer knows nothing about Business or UI layer. Business layer knows about Data layer, but not about UI layer. UI layer knows about Business layer, but not about Data layer.

enter image description here

Do you use either of these? Which one? Why? Do you use a different approach?

The way I see it, #1 offers a business-centric method of doing things. UI can be easily changed as can data layer without affecting business layer.

The second is more straight forward, and typically would require that the business layer change if the data layer changes. Of course, you can abstract this with well planned interfaces, (like a Repository pattern, but somewhere this needs to change). UI can be changed without affecting either.

1
architecturesoftware-designn-tier-architecture
for what it's worth, I don't see any problem with either approach; both provide good modularity and abstraction. Personally I use the second approach you described, as it seems more straight-forward to me. – J. Ed
relevant: jeffreypalermo.com/blog/the-onion-architecture-part-1 – Arnis Lapsa
a good overview of the 3-tier concepts: exforsys.com/tutorials/application-development/… – Jowen

1 Answers

0
votes

if it's a CURD application with little business logic, use approach #2. otherwise, use approach #1, it's actually a result of applying Inversion of Control (IoC) to #2.