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?
asp.net
asp.net-mvc
japzdivino
źródło
źródło
Odpowiedzi:
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:
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.
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.
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:
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.
źródło
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.
źródło
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ł.
źródło