Is Layered architecture useful without any design pattern like DI or Repository?

Question

I'm a little bit confused on this matter: is layered architecture useful without any design pattern like DI or Repository? I'm not talking about direct DI and Repository patterns; they are just examples. As per my knowledge, we use layered architecture mainly to remove dependencies across layers; but without using the above mentioned design patterns, we just code direct references to those layers. As an example if we have a Logic layer and Database layer without any design pattern, we heavily couple each layer. Can anyone explain this?

Answer 1

I don't know if I would necessarily call it heavy coupling. I'll use a Java application as an example. Imagine that your layers are as follows:

UI -> Business Logic -> Data Access

Your UI layer might contain a Java servlet (that knows how to display data), while your business logic layer contains an EJB (that knows how to do business validations, etc), and your data access layer might use straight-forward JDBC connection to store data into MySQL.

Your UI layer isn't coupled to specific validation logic, and your business logic layer isn't coupled to a specific DB implementation. If you want to swop out your JSP with a Swing app for the presentation layer, it's easy - the validation and persistence logic is decoupled. Sure, the Swing app will have to get a reference to the entry-point for the business logic layer, but that's fine. If you want to replace MySQL with Postgres, that's fine too - your presentation- and business logic layers won't be affected. Of course, each layer will have to have its own data transfer objects - as soon as you use one DTO all the way from the UI layer right down to persistence, any changes will propogate all the way through, and that's something you don't want.

Granted, if you use DI it might make refactoring a bit easier, but not using DI doesn't invalidate the benefits of having a layered architecture. Even a simple facade that handles communication between layers will already make it easier to refactor. Think of it in terms of the Single Responsibility Principle as well.

Answer 2

Layer architecture is software architecture where layers are (physically) separated.
Examples: multi layer , network osi layers

In Java you if all source code is in one project you can use package names for layering if you have multi project then layering can be defined on project level.

Dependency Injection pattern is way how to write a code with "programing against interfaces" principle, so there is no direct relation.

Answer 3

Simple answer: Yes.

Longer answer: Layered Architecture is almost always a design goal of a good developer, regardless of what project they are working on(assuming a project of sufficient size at least + good developer).

Layered Architecture at its most fundamental concept is just "division of labor" into "logical units"... which sounds a lot like 'methods'. Technically you can write an entire 10,000 line java program in a single class inside the main method... but obviously it is beneficial(regardless of what other design decisions you make) to sub-divide your program into packages, classes, and methods based on grouping of similar code(I'm being VERY broad here). So multi-layered arch. is just another level of 'abstraction' to assist in dividing an application into different 'parts'.

Even without the use of DI, etc. Designing your application to use a set of interfaces to define interactions between different components will not only assist you in developing alternative implementations of different layers(which would then be easy to change via a few lines of code for testing before final integration/merging) but it also will help you mentally design your project better. This is more of an 'experience' thing, but having a good guideline like mutli-layers helps you more quickly make the decisions of what parts should be part of which layers, etc.

It can also help with dividing the workload and reducing the number of issues when you go to merge everyone's code. For example, in my undergraduate software engineering course we designed a 3 layered program and we used ui, logic, storage as our 3 layers and besides defining 3 segments of the code, we were then able to divide the workload among the group and finally combine our different parts with 0 hassle.

Answer 4

Looking at your question, I assume that you are asking about 3-Tier Layered Architecture (Database | Business Logic | UI). I would first list your questions and thoughts, then emphasize the overall picture.

(1) Is Layered architecture useful without any design pattern?

(2) we use layered architecture mainly to remove dependencies across layers.

(3) but without using the above mentioned design patterns, we just code direct references to those layers.

(4) without any design pattern, we heavily couple each layer.

In above [(1) & (2)] and [(3) & (4)] are related with each other.

I'll first talk about (1) & (2). Simply, Layered Architecture makes up our application into 3 isolated layers. It addresses a System-level concern. Some advantage, we follow LA are

• Since we have separated out the UI layer and it's not mixed with lower levels, we can reuse same server (assume an API with Database + Business Logic) for different UI (web & mobile).
• I we develop stand-alone desktop app, we can reuse same (Business Logic + Database) and build a mobile app.

If I talk about (3) & (4), Design patterns are simply problem-solution pairs, which we often get involved with. So it describes an answer for a general-problem . In different with Layered-Architecture, Design Patterns addresses class-level .

One thing I notice in your description is you believe that not-using design patterns will lead a bad-code. Actually it is not. And conversely if we add a design pattern in a wrong way, we would get ended up with creating an anti-pattern and going to suffer high time. As I said it's an answer for a general problem, but your practical problem will be much specific one for your system. So how good you can tailor that general one into the specific will really matter. In simplest terms, if you are good at utilizing basic OOP principles and good at keeping the things simple, you might not need a thing called design patterns at all. And you have used design patterns in your code would not necessarily claim that you have a solid code (This does not claim that design patterns are a bad concept). In fact there are some design patterns which are not very good in general. And there are very good ones too.

As a direct answer for your main question. Those 2 are not much interrelated. I agree that there is a little. But more over they are two different things which addresses different context. :))