N-Tier 아키텍처 란 무엇입니까?

N-Tier 아키텍처 란 무엇입니까?

---

최근에 "N-Tier 아키텍처에 대한 경험이 있어야합니다"또는 "N-Tier 앱을 개발할 수 있어야합니다"라는 문장이 포함 된 개발자 구인 게시가 많이있었습니다.

N-Tier 아키텍처 란 무엇입니까? 어떻게 경험을 쌓을 수 있습니까?

---

위키 백과 :

소프트웨어 엔지니어링에서 멀티 티어 아키텍처 (종종 n 티어 아키텍처라고 함)는 프리젠 테이션, 애플리케이션 처리 및 데이터 관리가 논리적으로 별개의 프로세스 인 클라이언트-서버 아키텍처입니다. 예를 들어 미들웨어를 사용하여 사용자와 데이터베이스 간의 데이터 요청을 처리하는 응용 프로그램은 다중 계층 아키텍처를 사용합니다. "멀티 티어 아키텍처"의 가장 널리 사용되는 것은 3 티어 아키텍처입니다.

"계층"으로 간주되는 것은 논란의 여지가 있지만 적어도 프로세스 경계를 ​​넘어서는 것이 필요합니다. 아니면 레이어라고합니다. 그러나 물리적으로 다른 시스템에있을 필요는 없습니다. 권장하지는 않지만 논리 계층과 데이터베이스를 같은 상자에 호스팅 할 수 있습니다 .

편집 : 한 가지 의미는 프레젠테이션 계층과 논리 계층 (때때로 비즈니스 논리 계층이라고 함)이 때때로 신뢰할 수 없거나 느리고 안전하지 않은 네트워크를 통해 "전선을 가로 질러"경계를 넘어야한다는 것입니다. 이것은 데이터가 파일과 동일한 시스템에 있거나 데이터베이스를 직접 칠 수있는 웹 응용 프로그램과 같은 컴퓨터에있는 간단한 데스크톱 응용 프로그램과는 매우 다릅니다.

n 계층 프로그래밍의 경우 데이터를 "데이터 세트"라고하는 일종의 전송 가능한 형태로 패키지화하여 와이어로 전송해야합니다. .NET의 DataSet 클래스 또는 SOAP 와 같은 웹 서비스 프로토콜 은 와이어를 통해 객체를 비행하려는 시도가 거의 없습니다.

---

핵심 비즈니스 로직 및 데이터 액세스와 프레젠테이션 계층을 분리하는 방법을 기반으로합니다 ( Wikipedia )

3 계층 은 프리젠 테이션 계층 + 컴포넌트 계층 + 데이터 액세스 계층을 의미합니다. N- 계층은 불필요한 레이어가이 세 개를 넘어서 추가 될 때 유행어로 표시되어 있으므로 건축가가 많은 균열 원숭이처럼 보이지 않습니다. 나는 이것이 내가 작업 해야하는 N 계층 아키텍처를 기반으로한다고 말합니다.

---

Javascript-ASP.Net-Middleware-Database 레이어와 같은 일반적인 웹 아키텍처와 같은 것을 나타내는 용어입니다. 이들 각각은 "계층"입니다.

---

N 계층 데이터 애플리케이션은 여러 계층으로 분리 된 데이터 애플리케이션입니다. "분산 응용 프로그램"및 "멀티 티어 응용 프로그램"이라고도하는 n- 티어 응용 프로그램은 처리를 클라이언트와 서버간에 분산 된 개별 계층으로 분리합니다. 데이터에 액세스하는 응용 프로그램을 개발할 때는 응용 프로그램을 구성하는 다양한 계층을 명확하게 구분해야합니다.

일반적인 n 계층 응용 프로그램에는 프레젠테이션 계층, 중간 계층 및 데이터 계층이 포함됩니다. n 계층 응용 프로그램에서 다양한 계층을 분리하는 가장 쉬운 방법은 응용 프로그램에 포함하려는 각 계층에 대한 개별 프로젝트를 만드는 것입니다. 예를 들어 프레젠테이션 계층은 Windows Forms 응용 프로그램 인 반면 데이터 액세스 논리는 중간 계층에있는 클래스 라이브러리 일 수 있습니다. 또한, 프리젠 테이션 계층은 서비스와 같은 서비스를 통해 중간 계층의 데이터 액세스 로직과 통신 할 수있다. 응용 프로그램 구성 요소를 별도의 계층으로 분리하면 응용 프로그램의 유지 관리 성과 확장 성이 향상됩니다. 전체 솔루션을 재 설계 할 필요없이 단일 계층에 적용 할 수있는 새로운 기술을보다 쉽게 ​​채택 할 수 있습니다. 게다가,

Taken from Microsoft website.

---

If I understand the question, then it seems to me that the questioner is really asking "OK, so 3-tier is well understood, but it seems that there's a mix of hype, confusion, and uncertainty around what 4-tier, or to generalize, N-tier architectures mean. So...what's a definition of N-tier that is widely understood and agreed upon?"

It's actually a fairly deep question, and to explain why, I need to go a little deeper. Bear with me.

The classic 3-tier architecture: database, "business logic" and presentation, is a good way to clarify how to honor the principle of separation of concerns. Which is to say, if I want to change how "the business" wants to service customers, I should not have to look through the entire system to figure out how to do this, and in particular, decisions business issues shouldn't be scattered willy-nilly through the code.

Now, this model served well for decades, and it is the classic 'client-server' model. Fast forward to cloud offerings, where web browsers are the user interface for a broad and physically distributed set of users, and one typically ends up having to add content distribution services, which aren't a part of the classic 3-tier architecture (and which need to be managed in their own right).

The concept generalizes when it comes to services, micro-services, how data and computation are distributed and so on. Whether or not something is a 'tier' largely comes down to whether or not the tier provides an interface and deployment model to services that are behind (or beneath) the tier. So a content distribution network would be a tier, but an authentication service would not be.

Now, go and read other descriptions of examples of N-tier architectures with this concept in mind, and you will begin to understand the issue. Other perspectives include vendor-based approaches (e.g. NGINX), content-aware load balancers, data isolation and security services (e.g. IBM Datapower), all of which may or may not add value to a given architecture, deployment, and use cases.

---

It's my understanding that N-Tier separates business logic, client access and data from each other using separate physical machines. The theory is that one of them can be updated independently of the others.

---

N-tier data applications are data applications that are separated into multiple tiers. Also called "distributed applications" and "multitier applications," n-tier applications separate processing into discrete tiers that are distributed between the client and the server. When you develop applications that access data, you should have a clear separation between the various tiers that make up the application.

And so on in http://msdn.microsoft.com/en-us/library/bb384398.aspx

---

When constructing the usual MCV (a 3-tier architecture) one can decide to implement the MCV with double-deck interfaces, such that one can in fact replace a particular tier without having to modify even one line of code.

We often see the benefits of this, for instance in scenarios where you want to be able to use more than one database (in which case you have a double-interface between the control and data-layers).

When you put it on the View-layer (presentation), then you can (hold on!!) replace the USER interface with another machine, thereby automate REAL input (!!!) - and you can thereby run tedious usability tests thousands of times without any user having to tap and re-tap and re-re-tap the same things over and over again.

Some describe such 3-tier architecture with 1 or 2 double-interfaces as 4-tier or 5-tier architecture, implicitly implying the double-interfaces.

Other cases include (but are not limited to) the fact that you - in case of semi-or-fully replicated database-systems would practically be able to consider one of the databases as the "master", and thereby you would have a tier comprising of the master and another comprising of the slave database.

Mobile example

Therefore, multi-tier - or N-tier - indeed has a few interpretations, whereas I would surely stick to the 3-tier + extra tiers comprising of thin interface-disks wedged in between to enable said tier-swaps, and in terms of testing (particularly used on mobile devices), you can now run user tests on the real software, by simulating a users tapping in ways which the control logic cannot distinguish from a real user tapping. This is almost paramount in simulating real user tests, in that you can record all inputs from the users OTA, and then re-use the same input when doing regression tests.

---

When we talk of Tiers, we generally talk of Physical Processes (having different memory space).

Thus, in case, Layers of an application are deployed in different processes, those different processes will be different tiers.

E.g, In a 3-tier application, business tier talks to Mainframes (separate process) and talks to Reporting Service (separate process), then that application would be 5 tier.

Hence, the generic name is n-tier.

---

from https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/n-tier

An N-tier architecture divides an application tires into logical tiresand physical tiers mainly and their are divide to sub parts.

Layers are a way to separate responsibilities and manage dependencies. Each layer has a specific responsibility. A higher layer can use services in a lower layer, but not the other way around.

Tiers are physically separated, running on separate machines. A tier can call to another tier directly, or use asynchronous messaging (message queue). Although each layer might be hosted in its own tier, that's not required. Several layers might be hosted on the same tier. Physically separating the tiers improves scalability and resiliency, but also adds latency from the additional network communication.

A traditional three-tier application has a presentation tier, a middle tier, and a database tier. The middle tier is optional. More complex applications can have more than three tiers. The diagram above shows an application with two middle tiers, encapsulating different areas of functionality.

An N-tier application can have a closed layer architecture or an open layer architecture:

In a closed layer architecture, a layer can only call the next layer immediately down.
In an open layer architecture, a layer can call any of the layers below it.

A closed layer architecture limits the dependencies between layers. However, it might create unnecessary network traffic, if one layer simply passes requests along to the next layer.

---

Martin Fowler demonstrating clearly:

Layering is one of the most common techniques that software designers use to break apart a complicated software system. You see it in machine architectures, where layers descend from a programming language with operating system calls into device drivers and CPU instruction sets, and into logic gates inside chips. Networking has FTP layered on top of TCP, which is on top of IP, which is on top of ethernet.

When thinking of a system in terms of layers, you imagine the principal subsystems in the software arranged in some form of layer cake, where each layer rests on a lower layer. In this scheme the higher layer uses various services defined by the lower layer, but the lower layer is unaware of the higher layer. Furthermore, each layer usually hides its lower layers from the layers above, so layer 4 uses the services of layer 3, which uses the services of layer 2, but layer 4 is unaware of layer 2. (Not all layering architectures are opaque like this, but most are—or rather most are mostly opaque.)

Breaking down a system into layers has a number of important benefits.

• You can understand a single layer as a coherent whole without knowing much about the other layers. You can understand how to build an FTP service on top of TCP without knowing the details of how ethernet works.

• You can substitute layers with alternative implementations of the same basic services. An FTP service can run without change over ethernet, PPP, or whatever a cable company uses.

• You minimize dependencies between layers. If the cable company changes its physical transmission system, providing they make IP work, we don’t have to alter our FTP service.

• Layers make good places for standardization. TCP and IP are standards because they define how their layers should operate.

• Once you have a layer built, you can use it for many higher-level services. Thus, TCP/IP is used by FTP, telnet, SSH, and HTTP. Otherwise, all of these higher-level protocols would have to write their own lower-level protocols. From the Library of Kyle Geoffrey Passarelli

Layering is an important technique, but there are downsides.

• Layers encapsulate some, but not all, things well. As a result you sometimes get cascading changes. The classic example of this in a layered enterprise application is adding a field that needs to display on the UI, must be in the database, and thus must be added to every layer in between.

• 여분의 레이어는 성능을 저하시킬 수 있습니다. 모든 레이어에서 사물은 일반적으로 한 표현에서 다른 표현으로 변환되어야합니다. 그러나 기본 함수의 캡슐화는 종종 보상 이상의 효율성 향상을 제공합니다. 트랜잭션을 제어하는 ​​계층을 최적화하면 모든 것이 더 빨라집니다. 그러나 계층 구조에서 가장 어려운 부분은 어떤 계층을 갖고 있고 각 계층의 책임은 무엇인지 결정하는 것입니다.

참고 URL : https://stackoverflow.com/questions/312187/what-is-n-tier-architecture