Aplikacje WCF/Client - gdzie powinna iść logika biznesowa?

Budujemy usługę WWW WCF przy użyciu WSSF. Chodzi o to, że wystawi ona naszą główną bazę danych za pośrednictwem usługi i pozwoli nam budować różne aplikacje i strony internetowe na szczycie usługi. W tej chwili buduję prostą aplikację kliencką, która pobierze niektóre dane z tej usługi, zmanipuluje ją, a następnie przekaże użytkownikowi jako plik CSV raportu.Aplikacje WCF/Client - gdzie powinna iść logika biznesowa?

Teraz pytanie brzmi, gdzie powinna znajdować się logika biznesowa (która manipuluje danymi)? Pomyślałem, że umieściłbym go w serwisie. Mam już tam warstwę biznesową z prostymi obiektami, które mapują prawie jeden do jednego z bazą danych (klient, zamówienie itp.). Pomyślałem, że zrobię obiekty "wyższego poziomu", aby manipulować danymi. Na przykład za pomocą klienta, zamówienia i innych obiektów i sporządzenie raportu itp. Myślałem, że najlepszym miejscem na to będzie w warstwie biznesowej dla usługi. W ten sposób moglibyśmy ponownie użyć tej logiki dla różnych różnych aplikacji, jeśli zajdzie taka potrzeba.

Niestety mój szef się nie zgadza. Chce "oddzielenia obaw" i powiedział, że właściwym miejscem dla tej logiki będzie warstwa biznesowa wewnątrz aplikacji klienta, a nie w usłudze. Myślę, że to może być prostsze, ale chciałbym użyć mojego potężnego modelu obiektu wewnątrz warstwy biznesowej usługi, aby napisać ten kod. Obiekty odsłonięte przez usługę nie są "rzeczywistymi" obiektami i są w rzeczywistości strukturami danych o niewielkiej masie, bez mocy modelu pełnego obiektu, który istnieje wewnątrz warstwy biznesowej usług.

Co wy myślicie? Wielkie dzięki za pomoc.

Cheers Mark

Źródło

2009-12-02 Mark Evans

zapytaj go: czy potrzebujemy innego klienta, czy powinniśmy powielić całą logikę biznesową, czy użyć scentralizowanej wersji? –

Kontynuując z logiką @Rubens Farias, jeśli logika biznesowa musi zostać naprawiona i znajduje się ona w kliencie, wtedy * wszyscy * klienci muszą zostać zaktualizowani. Jeśli jest w usłudze, to tylko ta usługa musi zostać zaktualizowana. –

Dzięki za odpowiedzi. Tak, myślę też, że ponowne wykorzystanie jest fajne. Sądzę, że głównym minusem jest to, że aktualizacja usługi może spowodować zerwanie wszystkich istniejących klientów. –

myślę, co jest "poprawne" zależy od architektury aplikacji. Jest z pewnością wartość w oddzieleniu obaw. Wygląda na to, że twój szef uważa, że obecny model ma używać serwera jako warstwy dostępu do danych, która mapuje bazę danych do obiektów biznesowych i że logika biznesowa powinna być zaimplementowana na kliencie.

Nadal można rozdzielić wątpliwości, czy logika biznesowa jest zaimplementowana na kliencie czy serwerze. Nie jest to miejsce, w którym liczy się przetwarzanie, ale jak łatwo zaprojektowałeś interfejsy między warstwami aplikacji.

Może pomóc dowiedzieć się więcej o kliencie. Czy masz do czynienia z przeglądarką/klientem Javascript? Jeśli tak, to będę przechowywać możliwie jak najwięcej przetwarzania na serwerze i wysłać dane do klienta mniej więcej w formie, która ma być wyświetlana.

Jeśli jest to klient C#, to masz na to dużo więcej mocy do pracy. Prawdopodobnie można odtworzyć odpowiedzi usługi WCF na te same klasy obiektu biznesowego, które były używane po stronie serwera i uzyskać taką samą moc, jaka była na serwerze. (Wystarczy udostępnić klasy obiektów biznesowych między dwoma rozwiązaniami.)

Źródło

2009-12-02 02:08:24

Dzięki za komentarze. Będą 2 składniki klienta do tego konkretnego użycia usługi internetowej WCF. Aplikacja internetowa Asp.NET, a także usługa .NET Windows. Oznacza to, że na końcu klienta nie brakuje mocy. Właściwie wydaje mi się, że nie można ujawnić standardowych obiektów biznesowych (takimi metodami jak Save() i właściwości, które ładują się na żądanie itp.) W serwisie WWW WCF. Obiekty, które eksponuje, to proste struktury danych zwane "umowami danych". –

Dane DataContract/DataMember to zasadniczo interfejs do obiektu, który określa sposób, w jaki jest wysyłany przez sieć. Nadal możesz umieścić tam wszystkie rodzaje metod. Same metody nie są wysyłane za pośrednictwem żądań usług sieciowych, ale występują na obu końcach jako część definicji klasy, o ile obie aplikacje używają tej samej biblioteki obiektów biznesowych. Oczywiście niektóre operacje, takie jak Save(), mogą się zdarzyć tylko na jednym lub drugim końcu (Save() musi się zdarzyć na serwerze). Z drugiej strony klient może mieć metodę ClientSave(), która wywołuje metodę składowania usługi. –

To bardzo interesujący Nate. Nie rozważałem tej możliwości. Myślę, że lepiej byłoby trzymać obiekty biznesowe w warstwie biznesowej itp. Chociaż jest to problem przekształcający obiekty warstwy danych w obiekty warstwy biznesowej na obiekty warstwy usług ... –

Nie ma na to sztywnych reguł, ale w tym przypadku powiedziałbym, że twój szef jest bardziej nie tak niż ty :) Każdy będzie miał nieco inny opinia na ten temat i może istnieć wiele powodów, dla których logika biznesowa jest umieszczana w miejscach innych niż warstwa biznesowa, ale rzadko istnieje powód, aby umieścić ją w aplikacji klienckiej - można argumentować, że gdy jest ona w kliencie jest to raczej reguła interfejsu użytkownika lub prezentacji niż reguła biznesowa.

Jeśli serwisy internetowe mają być używane przez wiele aplikacji, to w największym możliwym stopniu logika biznesowa po stronie usługi internetowej. W rzeczywistości miałbym bardzo cienką warstwę usługi sieciowej, wystarczy tylko zaakceptować wywołanie, a następnie przekazać wykonanie do rzeczywistej warstwy biznesowej. Miałbym również mapowanie danych baz danych i jednostek danych biznesowych w warstwie bazy danych, a nie w warstwie biznesowej.

Źródło

2009-12-02 02:17:01 slugster

Witam Slugster Tak, to architektura za pomocą. Warstwa danych to ADO Entity Framework i mam warstwę biznesową z obiektami zapełnionymi za pomocą obiektów Entity Framework. Ta warstwa zawiera większość kodu. Warstwa usługi WWW WCF jest zbudowana przy użyciu WSSF (Web Service Software Factory). Ta warstwa konwertuje tylko obiekty biznesowe na komunikaty WCF. –

Mój głos będzie jasne:

umieścić jak najwięcej kontroli integralności danych w bazie danych
umieszczać żadnych innych kontroli logiki biznesowej w warstwie logiki biznesowej po stronie serwera usługi
umieść tylko proste sprawdzenia, takie jak "wymagane pole" itp. W warstwie klienta, optymalnie automatycznie określane na podstawie modelu bazy danych lub modelu biznesowego

Dlaczego baza danych? SQL w dowolnym kształcie lub formie ma bardzo proste i bardzo wydajne możliwości sprawdzania - upewnij się, że rzeczy są wyjątkowe, upewnij się, że relacyjna integralność tabel jest podana i tak dalej - WYKORZYSTAJ IT! Jeśli wykonasz te sprawdzenia w bazie danych, to bez względu na to, w jaki sposób twój użytkownik ostatecznie połączy się z twoimi danymi (scenariusz horroru: menedżerowie mogą łączyć się bezpośrednio z twoimi tabelami za pomocą Excela, aby wykonać pracę Business Intelligence ......), kontrole będą na miejscu i będą egzekwowane. Egzekwowanie integralności danych to najwyższy wymóg w każdym systemie.

Dlaczego logika biznesowa na serwerze?
Z tego samego powodu, o którym wspomnieli inni oferenci: centralizacja. Nie chcesz logiki biznesowej i czeków tylko w kliencie. Co się stanie, jeśli jakiś inny dział w twojej firmie lub zewnętrzny konsultant zewnętrzny zacznie nagle korzystać z twojej usługi, ale wszystkie sprawdzenia poprawności i kontroli biznesowej nie są na miejscu, skoro o nich nie wiedzą? Nie jest dobrą rzeczą ......

Logic w kliencie
Tak, oczywiście - również chcesz umieścić kilka prostych czynności sprawdzających do klienta, zwłaszcza jeśli jest to aplikacja internetowa. Rzeczy takie jak "to pole jest wymagane" lub "maksymalna długość dla tego pola" itp. Powinny być egzekwowane jak najwcześniej. W idealnej sytuacji będzie on automatycznie pobierany przez klientów z warstwy bazy danych/usługi. Kontrolki serwera ASP.NET mają funkcję sprawdzania poprawności klienta, która może być automatycznie włączona, usługi RIA Silverlight mogą pobrać ograniczenie danych w modelu danych backend i przenieść je do warstwy klienta.

Źródło

2009-12-02 05:40:13

Dzięki za szczegółową odpowiedź Marc. Na pewno zgadzam się z wszystkimi twoimi komentarzami! Domyślam się, że logika, o której mówię, polega na agregowaniu danych z kilku miejsc do raportu lub eksportu jakiegoś rodzaju pliku. To nie tyle sprawdzanie integralności itp. Jednak z twoich komentarzy i innych wydaje się, że większość programistów umieszcza tego rodzaju rzeczy również w warstwie usług biznesowych. O wiele łatwiej będzie się rozwijać, jeśli mam dostęp do pełnowymiarowych obiektów biznesowych w tej warstwie, a nie do lekkich kontraktów danych ujawnianych przez usługę. Pozdrowienia Znak –

+1 z zastrzeżeniem. Czy jest możliwość (już niedługo się martwić), że twoi klienci mogą dywersyfikować, tj. Klienci wymagają nieco innej logiki, korzystania z usług strony trzeciej lub szerszego, bardziej uogólnionego użycia. W tych okolicznościach jeden scentralizowany BLL może mieć dużo logiki kontrolnej, aby ustalić, co zrobić dla każdego klienta. OK, więc wprowadzenie warstwy abstrakcji w warstwie serwisowej może pomóc i zwykle daje efekt. Nie ma powodu, dla którego nie można logicznie oddzielić obawy, ale fizycznie/wdrożeniowo je połączyć. Ciasto i zjeść? – MattC

@MattC: tak, prawda - jeśli potrzebujesz obsługiwać kilku klientów, Twoje wymagania mogą się różnić. Ale nadal uważam, że nawet posiadanie trzech, pięciu różnych zestawów reguł sprawdzania poprawności na serwerze jest łatwiejsze do zarządzania niż posiadanie dziesiątek lub setek klientów do aktualizacji .... –

Aplikacje WCF/Client - gdzie powinna iść logika biznesowa?

Odpowiedz

Powiązane problemy