2009-07-27 8 views
6

Zrobiłem to Wiki Społecznościowe, ponieważ niektórzy mogą sądzić, że jest otwarte na debatę, a inni mogą myśleć, że jest to kwestia użycia słów do oznaczenia oni naprawdę znaczą (innymi słowy, to kwestia opinii, czy to kwestia opinii).WF, WCF i usługi deklaracyjne (lub: co Microsoft ma na myśli przez "deklaratywny"?)

Jest general question on SO about declarative programming, który ma kilka świetnych odpowiedzi.

Ale jestem trochę rzucony przez this blog post od ewangelisty Microsoftu.

Jedną z zalet programowania deklaratywnego jest to, że można wskazać co chcesz zrobić, ale nie jak to zrobić.

Do tej pory, tak dobrze - że dokładnie zgadza się z zaakceptowaną odpowiedzią na pytanie SO, w rzeczywistości.

Ale wtedy sprawdzić część o „realizacji usługi”

Można wystarczy spojrzeć na kilkudziesięciu liniach xaml kodu i być w stanie określić, w jaki sposób WCF Usługa jest skonfigurowana i jak zdefiniowany jest odpowiedni przepływ pracy .

Po obejrzeniu kilku przykładów, pozwól mi krótko odpowiedzieć na to, mówiąc "Nie, nie mogę". Ale zamiast lekkomyślnie odrzucić te rzeczy, pozwólmy, look at the docs.

Zajęło to trochę czasu, ale ostatecznie reality has caught up with satire ... ale to nie o to chodzi - oczywiście nie sugerują poważnie, aby zrobić to, aby odsłonić coś trywialnego, jak dodanie. Nie narzekam też na śmieszną gadatliwość i dziwny pomysł, że ktokolwiek kiedykolwiek napisze coś podobnego ręcznie - wygląda bardziej na wynik kompilatora niż na języku czytelnym dla człowieka.

Dla mnie zagadką jest to, że jest to deklaracja "deklaratywna". A jednak sednem tego jest oświadczenie o przydziale.

There's more here:

usługi deklaratywne są zdefiniowane deklaratywnie w XAML i zapewniają kolejną warstwę abstrakcji. Zasadniczo tworzysz model usługi , definiując, co chcesz zrobić, a nie jak zrobić , a nie jak zrobić . Cała usługa może być zdefiniowana jako deklaracja , w tym implementacja operacji .

Więc jeśli mówimy deklaratywny lub deklaratywnie trzy razy, to sprawia, że ​​deklaratywne. Mam cię. A jeśli powiemy magiczne zdanie "co chcesz zrobić, a nie jak to zrobić", możemy nie zauważyć, że w następnym zdaniu określimy "implementację operacji", a więc my zamierzają powiedzieć dokładnie, jak to zrobić.

Przykładem w tej stronie:

<wma:Sequence> 
    <wma:WriteLine Text ='[String.Concat(String.Concat(String.Concat(String.Concat("Add(", CType(op1, Object)), ","), CType(op2, Object)), ") called")]' /> 
    <wma:Assign x:TypeArguments="xs:Int32" To="[result1]" Value="[op1 + op2]" /> 
</wma:Sequence> 

To znaczy, cała rzecz (w tym tony śmieci mam wycięty z przykładu WF) jest dokładnie równoważne:

void Add(int op1, int op2, out int result1) 
{ 
    Console.WriteLine("Add(" + op1 + ", " + op2 + ") called"); 
    result1 = op1 + op2; 
} 

Tak - blok instrukcji, które mają być wykonane w kolejności, w jakiej się pojawiły, i mieć efekty uboczne. Są oczywiście elementy workflow do zapętlenia (i możesz pisać własne działania, jeśli WF nie ma jeszcze twojego ulubionego polecenia). Najwyraźniej "przepisanie kodu w nieczytelnym formacie" jest tym samym, co "dodanie warstwy abstrakcji".

Powtarzam, to nie jest szalona, ​​nieczytelna gadulność, na którą uskarżam się - to fakt, że jest to oczywiście absolutnie niezbędne imperialne programowanie w realizacji usługi, więc o co chodzi? Zanim się zorientujesz, przejdziemy przez nasze przepływy pracy w debugerze, próbując dowiedzieć się, która instrukcja przypisania zmutowała jaką wartość, lub dlaczego pętla ciągle krąży w kółko.

(Ironią jest to, że w wersji C#, jest to trochę bardziej deklaratywny, ponieważ nie określono, w jaki sposób kawałki sznurka powinny być łączone, dzięki czemu kompilator generuje mniej wywołań metody Concat.)

Czy zapisanie czegoś w XML powoduje, że jest on deklaratywny (a także mniej czytelny)?

Odpowiedz

3

Jeszcze jedno potwierdzenie, że używanie XML w pojemnościach innych niż format wymiany jest do bani.

"Definicje" usług w WCF mają charakter deklaratywny od pierwszego dnia. Jednak oddzielanie definicji interfejsów od definicji usług (przez to mam na myśli ServiceContractAttribute i innych) jest, IMO, dobrze. Jednak używanie XML jako języka programowania jest naprawdę do bani.

Osobiście czuję się dość wytłumaczalnym atakiem czystego terroru patrząc na te dokumenty XML.

0

Istnieje część Windows Workflow Foundation, która nie jest omawiana (poza Microsoft), co może wyjaśnić to za Ciebie.

Jeśli utworzysz projekt przepływu pracy i zajrzysz do skrzynki narzędziowej, zobaczysz dużą liczbę "pól i linii", które możesz przeciągnąć na powierzchnię projektową. Możesz odnieść wrażenie, że masz stworzyć przepływy pracy z tego zestawu narzędzi. Tak nie jest.

Oczekuje się, że użytkownik utworzy niestandardowe działania specyficzne dla domeny problemu. Są one przeznaczone do połączenia z różnymi czynnościami po wyjęciu z pudełka. Są to prawdopodobnie działania na wysokim poziomie - takie jak "ocena polisy ubezpieczeniowej" lub "rejestracja pobytu pacjenta".

W deklaratywnym przepływie pracy (lub usłudze) zostanie zadeklarowane, jak przygotować dostępne dla Ciebie działania związane z konkretnymi problemami.

+0

"Deklaracja sposobu zestawiania" - ale tylko w tym sensie, że ciało metody w języku C# "deklaruje" sposób implementacji metody. Zwróć też uwagę na pojawienie się słowa "jak", a tego właśnie powinno unikać programowanie deklaratywne. Jaka jest granica między deklaratywną a imperatywną, zważywszy, że działania związane z przepływem pracy wykonywane przez usługę są zazwyczaj koniecznymi krokami (bez względu na to, czy są masywne), a więc muszą działać w sekwencji imperatywnej i sklejone przez imperatywne, gotowe do użycia czynności WF ? –