Różnica między architekturą 3-poziomową a MVC (model, kontroler widoku) w ASP.Net

Chciałbym wiedzieć, czym różni się architektura 3-poziomowa od MVC (Model, View Controller) w ASP.Net, ponieważ wydaje mi się, że ta sama architektura ma zastosowanie.

W 3-tier mamy User Services Layer, BusinessLayeri DataAccessLayer, z drugiej strony mamy na Model, View, i Controller. Wydaje mi się, że to ta sama architektura.

Czy ktoś może wyjaśnić, co tak naprawdę różni się od dwóch architektur, jak każda warstwa różni się od siebie?

To tak, jakby zapytać, jaka jest różnica między jabłkiem a rdzeniem jabłka. Te dwie architektury nie zastępują się nawzajem. Uważam, że bardziej dokładny widok jest taki, że architektura 3-poziomowa rozszerza MVC.

Architektura MVC

• Modele: reprezentują one „rzeczy” w twojej aplikacji. Ta warstwa stała się nieco rozmyta w ostatnich latach, co wyjaśnię później.

• Widoki: interfejs użytkownika. Rzecz, z którą użytkownik wchodzi w interakcje.

• Kontrolery: kod programowania, który reaguje na użytkownika i zmiany w warstwie modelu

Architektura 3-poziomowa

Dzięki architekturze trójwarstwowej masz warstwy o różnych obowiązkach.

• Usługi użytkownika: (lub ogólnie „usługi”) Ta warstwa dotyczy koordynowania pobierania i modyfikacji warstwy „modelowej”. Tutaj wykonywane są złożone, wieloetapowe działania

• Warstwa biznesowa: reprezentuje reguły biznesowe wyryte w kodzie programowania. To, czego chce „Firma”, jest egzekwowane w tej warstwie.

• Warstwa dostępu do danych: jedna lub więcej klas odpowiedzialnych za dostęp do trwałego magazynu danych.

Jedyną częścią trójwarstwowej architektury, która przecina się z MVC, jest „warstwa biznesowa”. „Modele” w MVC i „Warstwa biznesowa” w architekturze trójwarstwowej starają się osiągnąć ten sam cel.

„M” w MVC stało się rozmyte

Warstwa „modelowa” w MVC rozwinęła się w ostatnich latach. Z tego, co widziałem, istnieją dwa, być może trzy rodzaje modeli:

1. Modele domen: reprezentują one „rzeczy”, którymi interesuje się „Biznes” - Domena Biznesowa. Klasy te przechowują dane i wszystkie procedury, które działają na tych danych w celu egzekwowania reguł biznesowych. Często modele domen są powiązane z tabelami w bazie danych. Wydaje się, że pasuje to do „warstwy biznesowej” architektury 3-warstwowej.

2. Modele widoków: są to klasy używane do masowania danych z modeli domenowych w coś łatwiejszego do oglądania. Nie pasuje to nigdzie w architekturze trójwarstwowej, ponieważ modele widoków nie implementują logiki biznesowej ani nie zapewniają żadnej usługi ani dostępu do danych.

3. Modele biznesowe: w złożonych aplikacjach pojawia się potrzeba oddzielenia modelu domeny od logiki biznesowej. Modele biznesowe zawierają dane i procedury działające na tych danych w celu wdrożenia reguł biznesowych, a modele domen są przenoszone do „worków właściwości” - obiektów, które przechowują dane, ale nie zachowują się. Modele domenowe stają się kolejną formą obiektu do przesyłania danych między bazą danych a aplikacją.

Nigdzie w MVC nie wspomniano o dostępie do danych. W niektórych przypadkach zobaczysz, że dostęp do danych należy do „modelowej” warstwy MVC, która, jak widzieliśmy, nie jest już wyraźną warstwą wyciętą. Naprawdę widzę, że architektura 3-warstwowa jest łączona z MVC w celu stworzenia całej aplikacji. Jeden zwiększa lub ulepsza drugi:

• Modele
  • Modele domen (MVC / 3-tier)
  • Zobacz modele (MVC)
  • (opcjonalnie) Modele biznesowe (MVC / 3-poziomowe)
• Wyświetlenia (MVC)
• Kontrolery (MVC)
• Dostęp do danych (3 poziomy)
• Usługi (3-poziomowe)

Istnieje pewne skrzyżowanie, ale są one w dużej mierze oddzielne i razem służą do oddzielania i izolowania różnych elementów większego systemu.

Nie, nie są tacy sami.

MVC to wzorzec projektowy służący do strukturyzacji kodu interfejsu użytkownika. Można go zastosować w architekturze trójwarstwowej, w którym to przypadku wzorzec należałby do warstwy usług użytkownika. Ale może być również używany do interfejsu użytkownika w aplikacjach, które nie są trójwarstwowe - np. Kalkulator bez podstawowej trwałości, a zatem bez warstwy dostępu do danych.

W architekturze trójwarstwowej z nakładką MVC obiektami domeny używanymi jako model byłyby obiekty z warstwy biznesowej, ale wzorzec MVC tak naprawdę nie określa, jakiego rodzaju obiektami jest model, tylko jaka jest ich rola we wzorcu jest. Na przykład w wariancie MVVM modelami są adaptery specyficzne dla interfejsu użytkownika na obiektach domeny. W tym przypadku nawet model należy do warstwy usług użytkownika.

Wiem, że będzie mnóstwo różnych odpowiedzi, ale dam ci mój pogląd na ten temat.

To najbardziej znana odpowiedź w inżynierii oprogramowania „To zależy”.

Zasadniczo, jeśli spojrzysz na to, oprócz różnych implementacji i różnic teoretycznych są to bardzo podobne wzorce o podobnych przepływach.

Gdy zależy od tego, którą aplikację budujesz, prosta aplikacja internetowa może mieć tylko warstwę MVC komunikującą się z bazą danych do bazy danych. Bardziej złożony może mieć MVC obsługujący interfejs użytkownika w warstwie użytkownika, z bardziej złożonymi operacjami nie narażonymi na działanie użytkownika, które występują w warstwie BL, przy czym warstwa danych składa się z wielu źródeł.