Porady dla początkujących O N-Tier Applications

Question

Dobra ludzie, tu jest inny dla ya:

Zaczynam na świecie apps n-tier. Zrobiłem trochę czytania na ten temat i ogólne porady są takie, że celem aplikacji n-warstwowych jest abstrakcyjne warstwy kreacji funkcjonalności. Tak więc, na podstawie tego, w aplikacji n-warstwowych regularny model:

Data Access -> Business Layer -> Presentation

Ponieważ jestem programistą .NET, myślałem, że w celu zwiększenia integracji z wielu rodzajów klientów (Silverlight Web App lub nawet klient WinForm). Powinienem używać WCF (Windows Communication Foundation) jako usług danych w warstwie biznesowej, aby klienci mogli się z nim komunikować bez względu na jego typ. Ponadto, jestem wielkim fanem NHibernate jako ORM. Więc moja struktura wygląda tak:

Data Access (NHibernate) -> Business Layer (WCF) -> Presentation (WPF, ASP.NET, WinForms

Ok, więc jest to konfiguracja. Jestem totalną nowicjuszką w tego rodzaju podejściu, więc pomyślałem, że mógłbym opublikować tutaj, prosząc o radę na temat tej konfiguracji. Ponadto jestem bardzo zdezorientowany, jak to skonfigurować w rozwiązaniu VS, lubię rozdzielać warstwy w różnych projektach, ale co z abstrakcją obiektów danych (takich jak klient, zamówienie itp.)? Czy umieszczam je w osobnej bibliotece? A co z WCF? Wiem, że grzechem programisty jest przesyłanie klas danych przez kabel do klienta. Jaki jest profesjonalny sposób, aby to osiągnąć?

Dzięki, każda rada byłaby bardzo doceniana.

Answer 1

To prawie na cel. N-Tier jest nieco bardziej złożony niż N-Layer i można go skontrastować, pytając: "Czy twoje warstwy faktycznie żyją na oddzielnych fizycznych serwerach?"

W zależności od tego, jak skomplikowana jest twoja warstwa biznesowa, możesz ją dodatkowo rozrysować między warstwę biznesową i usługową. Zazwyczaj te dwie są ściśle związane i żyją na tym samym serwerze fizycznym. Warstwa usługi często działa jako fasada dla twojego BLL.

Jeśli warstwa prezentacji znajduje się na tym samym serwerze, aplikacje ASP.NET lub WinForm mogą chcieć komunikować się z BLL bez przechodzenia przez usługi WCF.

Przeczytaj na Microsoft Patterns & Practices - Application Architecture Guide.

Twoje obiekty domenowe powinny żyć we własnym zespole, zazwyczaj w modelu Twojej domeny. Według Microsoft Framework Design Guidelines, to dobra praktyka, aby wymienić swoje zespoły projektowe odpowiednio:..

[przedsiębiorstwo] [ProductOrComponent] [...]

zdarza mi się podoba ten format imienin odstępami i ogólnie używać:

....

[Spółka] [Produkt] [Warstwa] [podwarstwy] [...]

Oto przykład rozwiązanie wykorzystujące foldery rozwiązanie do organizowania każdego projektu:

I W tym przykładzie mam warstwę BLL i warstwę usługi. Warstwa usługi zapewnia rzeczywistą implementację w bibliotece WCF, podczas gdy prezentacja faktycznie zawiera aplikację WWW WCF do hostowania usług. Zawsze dobrą praktyką jest dzielenie implementacji z interfejsu.

Folder/Client można zignorować, po prostu używam tego jako przykładowej aplikacji konsolowej do testowania.Wszelkie aplikacje klienckie, które zużywają twoją usługę, powinny prawdopodobnie mieć własne rozwiązanie lub będziesz zarządzać ogromnym rozwiązaniem.

Co do obiektu danych przesyłanego przez kabel ... Zakładam, że masz na myśli klasy z ORM. (Model domeny) Masz rację, ogólnie uważa się, że jest to zła praktyka. Rozwiązaniem są obiekty przenoszenia danych. Na zdjęciu widzę bibliotekę .Dto. Jeśli jesteś w stanie używać narzędzi takich jak AutoMapper, niż ja to wszystko robię, to dodanie DTO do twojego rozwiązania niesie ze sobą dalszą złożoność i konserwację. Wierzę, że Dino Esposito napisał dobry artykuł na ten temat. Postaram się znaleźć to dla ciebie.

Mam nadzieję, że to pomoże.

---

[EDIT]

Należy zauważyć, że jestem zaznajomiony z możliwościami NHibernate jest. Mogą istnieć lepsze rozwiązania dla korzystania z tej ORM. Pracowałem tylko z Entity Framework.

---

[EDIT 2]

Wyjazd Dino Esposito - The Pros and Cons of Data Transfer Objects