Raportowanie a kodowanie - myśli?

Question

Niedawno miałem projekt, w którym musiałem pobrać dane z konkretnego oprogramowania do portletu. Oprogramowanie korzystało z bazy danych i spędziłem sporo czasu modelując dane, które chciałem, a następnie tworząc usługę internetową, aby mój portlet mógł pobrać informacje.

Nagle uderzyło mnie, że marnuję czas. Chwyciłem BIRT, wrzuciłem go do portletu, a następnie napisałem kilka raportów, które bezpośrednio pobierały potrzebne dane z bazy danych. Zrobiłem to po południu.

Rozumiem, że raportowanie to droga jednokierunkowa, ale to mnie zmusiło. Narzędzia do raportowania mogą być bardzo skuteczne w tworzeniu raportów (duh) z rzeczywistych danych, ale kiedy to robisz, pomijasz swój model, który oprócz prostych przypadków nie jest bezpośrednią reprezentacją twoich danych, ponieważ istnieje w twojej bazie danych.

Jeśli piszesz aplikację intensywnie wykorzystującą dane i chcesz mieć możliwość wykonywania nietrywialnych raportów, czy pomijasz aplikację i używasz czegoś takiego jak BIRT lub Crystal Reports? Jak zarządzać tymi narzędziami w ramach całego procesu? Czy uważasz, że raporty, które piszesz, są częścią twojej aplikacji i traktują je jako takie? Raport to widok, model i kontroler (jeśli chcesz) wszystko w jednym wielkim bałaganie, jak sobie z tym radzisz i interpretujesz i planujesz?

Zmienione pytanie: możliwe i powszechne jest, że raport wykona obliczenia biznesowe, które w idealnym świecie chciałbyś zawrzeć w swoim zgłoszeniu. Może to prowadzić do niedopasowania informacji przekazanych użytkownikowi. Z drugiej strony narzędzia do raportowania ułatwiają gromadzenie i wyświetlanie informacji, że trudno jest przyjąć podejście purystów i zrobić wszystko z poziomu aplikacji. Czy istnieją dobre techniki zapewniające zgodność danych w raportach z danymi wyświetlanymi w zwykłym GUI?

Answer 1

Raporty są częścią Twojej aplikacji, ale ponieważ są generalnie czymś, na co użytkownik będzie miał silne pomysły, np. Twój interfejs do przechwytywania danych, poświęcę czystość dla wygody/szybkości dostarczania i wrócę do "prawdziwego" kodowanie ... :-)

Zaraz po sporządzeniu raportu użytkownicy oczekują innego lub zmiany koloru lub opcjonalnego grupowania lub więcej filtrowania lub ... czegoś, co odciąga Cię od bardziej zwariowanych rzeczy ... więc nie popieram jelit utrzymując czystość.

Answer 2

Zgłaszanie jest kluczowe. Raportowanie ma zasadnicze znaczenie dla udostępniania wartości zebranych w jednym systemie zewnętrznym użytkownikom, np. użytkownicy, którzy nie korzystają bezpośrednio z systemu (np. zarządzanie danymi o sprzedaży). Raportowanie to o wiele więcej niż wyświetlanie faktów i liczb i jest czymś centralnym dla niemal każdego systemu, który napędza reklamę.

Przynajmniej bardziej zaawansowane systemy pozwalają na ich zwiększenie: dzięki własnym "kontrolom" wielokrotnego użytku. Nawet droga powrotna może zostać zaimplementowana - jeśli po prostu użyjesz poprawnych wtyczek. Kiedyś napisałem system do wysyłania e-maili z raportu, ponieważ system nie pozwalał na zmiany. Udało się - choć nie było to zamierzone w ten sposób;)

Raporty stanowią znaczną część aplikacji, a zyskujesz dużą swobodę, jeśli zmieniasz raporty dla swoich klientów. Czasami pojawia się więcej możliwości niż myślisz, kiedy zbudowałeś system w pierwszej kolejności.

Tak, tak, dla mnie raportowanie jest częścią systemu.

Answer 3

To naprawdę cienka linia. Nie chcesz poświęcać zbyt dużo czasu na tworzenie raportów (użytkownicy chcą, abyś cały czas zmieniał się), ale nie chcesz powielać logiki, umieszczając logikę biznesową w swoich raportach!Dzięki naszym produktom do raportowania w Data Dynamimcs, osiągnęliśmy szczęśliwe medium pomiędzy tymi dwoma kompromisami.

Korzystając z ObjectDataProvider (patrz linki poniżej, aby uzyskać więcej informacji), możesz powiązać raport bezpośrednio z obiektami biznesowymi (zwykłe stare obiekty), dzięki czemu nie musisz ominąć warstwy biznesowej w celu uzyskania danych. Jednocześnie udostępniamy sposób odnoszenia się i korzystania z funkcji z innych bibliotek w twoim raporcie. W ten sposób, jeśli masz już jakiś kod skonfigurowany do wykonywania pewnych obliczeń logiki biznesowej, możesz ponownie użyć tych funkcji bezpośrednio w raporcie. Możesz zobaczyć przykład tego w linkach poniżej.

• Wiązanie do obiektów dla danych (patrz „Obiekt Provider” fragment): http://www.datadynamics.com/Help/ddReports/ddrconDataSetAndObjectDataSource.html
• Dodawanie niestandardowego kodu do raportów Instrukcja: http://www.datadynamics.com/Help/ddReports/ddrwlkCustomCode.html
• Niestandardowe zestawy (przedstawieniu współdzielone biblioteki/DLL z raportu) : http://www.datadynamics.com/Help/ddReports/ddrconCustomCode.html i http://www.datadynamics.com/Help/ddReports/ddrtskCreatingAnInstanceMethod.html

Scott Willeke

danych Dynamics/GrapeCity

Answer 4

Sposób, w jaki zawsze pracowałem z raportami, polega na uwzględnianiu raportów części jako części podstawy kodu i przechowywanych w źródle wraz z aplikacją. W niektórych kontekstach raporty są ważniejsze niż aplikacja, ponieważ zarządzanie sprawia, że ​​decyzje biznesowe są wyłączane z danych raportu, a niewłaściwe informacje mogą spowodować anulowanie linii produktów, anulowanie kampanii lub zwolnienie sprzedawców. Oczywiście zależy to w dużym stopniu od zarządzania i aplikacji.

Jeśli chodzi o zachowanie spójności modelu, jest to nieco trudniejsze pytanie. Jednym ze sposobów zapewnienia spójnego modelu między raportami a aplikacją jest użycie procedur przechowywanych (lub widoków) w celu pobrania danych, w zależności od architektury aplikacji.

Answer 5

Widzę raportowanie jako po prostu inny widok danych, a nie widok/model/kontroler w jednym (no może widok i kontroler w jednym).

Mamy nasze raporty (wbudowane w usługi raportowania sql 2008) wykorzystują usługę w naszej warstwie aplikacji, aby uzyskać dane (zgodnie z naszym standardem, że dostęp do danych jest w repozytorium). Te funkcje mogą wykonywać proste zapytania lub obsługiwać bardzo złożone przetwarzanie, które byłoby koszmarem w środowisku raportowania lub w procedurze przechowywanej. W praktyce okazuje się, że trwa to dłużej niż kodowanie jednorazowej procedury przechowywanej, która, w miarę jak twój system rośnie i rośnie, staje się koszmarem do utrzymania.

Traktowanie zgłoszeń jako jednorazowych lub niezintegrowanych z projektem aplikacji jest ogromnym błędem.