Wypowiedzi
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści .NET
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści .NET
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści .NET
-
-
Robert B.:
Zainstalowałem gnokii, podpiąłem modem huawei, wstawiłem kartę w prepaid z "wykupionym" pakietem smsów po 0,01 zł do wszystkich w sieci.
(...)
Z tego co się orientuję takie rozwiązania są przez operatorów tępione, więc pewnego dnia numer może zostać zablokowany. Może to prawda, a może nieprawda - pewności nie mam. Tak czy siak radzę być na to przygotowanym (częsty monitoring, kilka zapasowych kart w zanadrzu etc...).
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści .NET
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści .NET
-
Spoko, ja nie mówię że to nie ma sensu:). Po prostu w moim przypadku praca przez X miesięcy bez wynagrodzenia nie wchodzi w grę, bo prawdziwe zaangażowanie i efekty wymagają czasu, którego nie można wtedy poświęcić na inne projekty. Zdaję sobie sprawę że to potencjalna inwestycja, ale najzwyczajniej w świecie - nie dla mnie, nie teraz.
A co do 10/20% szans na sukces... Udział nawet najlepszych programistów nie ma tu moim zdaniem wielkiego wpływu, bo sukces bądź jego brak jest wynikiem o wiele większej liczby czynników niż jedynie dobrego/złego kodu.
Tak czy siak - życzę powodzenia:).
-
-
Jarek Żeliński:
to mam na myśli to, że obiektowy opis dziedziny to nie implementacja a "model" jakiejś logiki np. biznesowej. Implementacją tak na prawdę jest istnienie obiektowych języków programowania czyli można "wstawić" obiektowy model dziedziny "wprost" do obiektowego projektu systemu i tu mam ów "ubiquitous language"
OK, tak przedstawiony pogląd podzielam, kwestia różnego rozumienia słowa "imeplementacja".
jeżeli na MVC spojrzymy tak, że jest to wzorzec, który między innymi wydziela Model jako "opis logiki systemu jako narzędzia pracy człowieka" i separuje od logiki sterowania "implementacją" to dokument będący modelem DDD jest "wsadem" 1:1 jako Model w MVC.
Można realizować DDD bez MVC, można realizować MVC bez DDD. Moim zdaniem nie ma tu żadnej zależności oprócz wspólnego słowa "model" oznaczającego dwie różne rzeczy. Model domeny może być modelem dla MVC, ale wydaje mi się że łączenie tych pojęć to mieszanie dwóch perspektyw.
Tak samo jak model domeny prawdopodobnie nigdy nie pokryje się z modelem relacyjnym reprezentującym dane w bazie.
ale DDD to nie model relacyjny ..... i RDBMS nie ma tu nic do rzeczy
Dokładnie o to mi chodziło - i w DDD mamy model(e), i w MVC mamy model, i w bazach danych mamy model. Każdy z tych modeli jest różny i powinien być rozpatrywany osobno.
-
Nie jestem pewny czy w 100% zrozumiałem problem (tzn na jakim poziomie operujemy pojęciem "firma-klient"), ale być może pojęcie "multi tenancy" jest tym czego szukasz.
Polecam lekturę postów na ten temat opublikowanych przez Ayende Rahien: http://ayende.com/blog/3530/multi-tenancy-approaches-a.... Ten link to chyba ostatni post z serii (przynajmniej na szybko nie znalazłem kolejnego), zawiera spis treści z linkami do wcześniejszych.
-
Jarek Żeliński:
Moim zdaniem DDD nie ma nic wspólnego z jakąś konkretną technologią (choć można z pomocą kodu ilustrować zastosowanie tej koncepcji analizy i projektowania) .... jest to raczej "metoda na przejście" od rzeczywistości do projektu koncepcyjnego bo nawet nie implementacji...
Z technologią - owszem, nie ma nic wspólnego.
Ale z implementacją - jak najbardziej! Właśnie po to jest "ubiquitous language" - żeby pojęcia z życia znalazły odwzorowanie tak w specyfikacji, jak i podczas analizy, ale również na poziomie kodu/testów, i w rozmowach między programistami. Przecież istnieje nawet całe podejście do tworzenia testów zrozumiałych dla "biznesu", gdzie testy same w sobie zawierają pojęcia stricte "domenowe" (mowa o BDD, przykładowe narzędzie dla .NET: SpecFlow).
Jarek Żeliński:
po drugie moim zdaniem mowa o DDD (gdzie kluczem jest Domain Model) w oderwaniu od np. wzorca MVC (także mamy tu ów Model) jest zupełna abstrakcją...
Albo nie zrozumiałem, albo nie do końca się zgodzę:). Model modelowi nierówny.
Model domeny nie musi być modelem w rozumieniu wzorca MVC (to już jest bardziej jeden z wielu sposobów komunikacji aplikacji z domeną, a osiągnąć to można na wiele sposobów, niekoniecznie stosując MVC/MVP/MV[whateva]).
Tak samo jak model domeny prawdopodobnie nigdy nie pokryje się z modelem relacyjnym reprezentującym dane w bazie.
-
Właśnie obejrzałem tą prezentację, ale szczerze mówiąc nie jestem zachwycony.
Nie wiem czy to wynika ze zbyt małego skupiania się na najważniejszych wg mnie koncepcjach (głównie bounded context) czy może z prostego faktu, że o DDD nie da się opowiedzieć w 40 minut. Odnoszę wrażenie, że gdybym wcześniej nie miał styczności z DDD, nie przeczytał "the blue book", to ta sesja niewiele by mi wyjaśniła.
Nie podobało mi się też "niejawne" przedstawianie DDD jako alternatywy dla SOA - moim zdaniem ze szkodą dla tego drugiego.
A jak Wasze wrażenia?
P.S. Przykłady Saga napisane są w C# z wykorzystaniem szyny NServiceBus, na stronie tego projektu można też więcej nich poczytać (http://nservicebus.com/Sagas.aspx). Polecam też lekturę bloga Udiego Dahana, twórcy NSB: http://www.udidahan.com/category/workflow/.
-
-
-
Kilka pytań:
1) "Za zaangażowanie i efekty wynagrodzimy udziałami!"
czyli przez pierwsze miesiące pracuje się da darmo z prawdopodobieństwem ~80-90% że projekt nie wypali?
2) "Prace nad projektem już trwają"
czyli programista nie będzie miał już za bardzo wpływu na architekturę systemu, sposób implementacji kluczowych elementów, modelowanie itd - bo to już jest?
3) "biuro w centrum Warszawy"
czyli wymagana fizyczna obecność w Warszawie przez następne miesiące?
----
edit: to o 80-90% bez żadnych złośliwości, po prostu wszycy chyba wiemy jak jestMaciej Aniserowicz edytował(a) ten post dnia 21.07.11 o godzinie 08:40
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści .NET
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści .NET
-
Nie wiem jak Flash, ale Silverlight wysyła normalne .NETowe dllki spakowane w pakiet, które można bez żadnego problemu podejrzeć np Reflectorem. Tak więc takie źródła są praktycznie równie otwarte co javascript (tyle że trzeba wykonać 2 dodatkowe kroki - rozpakowac xap i otworzyć dekompilator). Ew. wspomniana obfuskacja mogłaby tu w czymś pomóc.
-
Z powodu poważnego bugu w asp.net niektóre hostingi (w tym webio) powyłączały możliwość zmiany CustomErrors.
Skonfiguruj sobie ELMAH: http://www.webio.pl/BazaWiedzy/5,Zarzadzanie_Witrynami... i tam podglądaj błędy.
