Jakie są plusy i minusy przy użyciu wizualnych komponentów markowe Studio dla danych

Question

jestem dziedziczy kilka programów w pracy gdzie oryginalny autor użytych komponentów danych Microsoft Visual Studio (gdzie zbiór danych, adapter danych, etc) tworzą wewnątrz środowisko projektowe (z przybornika lub za pomocą kreatorów). Daje to pewne semiprofilowane (specjalistyczne dla danych) klasy, a także umieszcza kod SQL w klasach generowanych przez projektanta.

To nie jest sposób, w jaki jestem przyzwyczajony do robienia rzeczy (zawsze wolałem jednoznacznie mieć zestaw danych lub utworzyć własną wyspecjalizowaną klasę do przechowywania danych i ukrywania złożoności podstawowej warstwy danych).

Czy ktoś ma jakiś dobry wgląd lub linki Omawiając wady i zalety korzystania z komponentów danych Visual Studio?

(Uwaga na stronie, oryginalny autor także nie skomentował bardzo dokładnie i napisał, dla mojego gustu, trochę za dużo "sprytnego" kodu, który nie jest łatwo interpretowany, więc nie jestem skłonny myśleć, że on wie lepiej niż ja)

Przypuszczam inny sposób zadawania brzmi: Czy przy użyciu projektanta danych komponentów spowodować kodu, który jest „po najlepszych praktyk” i jest w utrzymaniu itp? Nie wydaje mi się, że tak jest, ale szukam informacji od ekspertów.

[EDIT: Dodano trochę więcej kontekst dla wyjaśnienia intencji]

Jeśli mam rację (i wygląda jak ja) na temat korzystania z komponentów markowe naprawdę jest najlepsza dla prototypów, itp, to jestem Będę musiał odbyć trudne rozmowy z oryginalnymi programistami i moim menedżerem. Chciałbym dodać więcej nacisku na "linki omawiające za i przeciw" część mojego pytania ... Szukam czegoś znaczącego, co mogę wykorzystać do poparcia swoich twierdzeń, że ten styl rozwoju/kod nie jest najbardziej odpowiedni do użytku produkcyjnego ... Dzięki.

Answer 1

Ogólnie wizualnych komponentów są za wyrzucenie aplikacji, POC i aplikacji Spike tj prototypowania. Jest tak z kilku powodów; bardzo szybko się ze sobą spotykają, ale kompletny koszmar do utrzymania. Jestem pewny rozmiaru aplikacji, ale jeśli to było do mnie byłbym twierdząc, że w jego obecna forma koszt eksploatacji będzie wzrastać z upływem czasu, a zatem będzie wyglądać na bardziej stylu DDD rozwoju. Odłóż warstwę danych i zastąp ją solidną ORM; NHibernate (preferowany) lub Entity Framework 4 (łatwiejszy dostęp). Upuść ten "sprytny kod" i zacznij korzystać z Kiss, Yagni, dry mantra.To może być trudne, aby je zobaczyć światło, ale gdy zaczyna kosztują mniej oni kochają cię za to;)

Jeśli chcesz trochę więcej czytania w tej dziedzinie spojrzeć na następujące:

1. Skill Matter to obiekt szkoleniowy, który uruchamia sesję otwartą i mnóstwo podcastów, które można oglądać:
2. Dobra książka dla programistów i dyrektorów, aby przeczytać to: Ship IT, przegląda dobre praktyki projektowe. Jak nic nie robi na pragmatyczne półce
3. Martin Fowlers' blog dla wszystkich rzeczą DDD
4. Ayende's blog jest doskonałym miejscem dla wszystkich rzeczy NHibernate
5. stackoverflow.com, to miejsce skały

Answer 2

VS elementy danych celem jest szybki rozwój aplikacji. Z tego punktu widzenia można zobaczyć jego zalety i wady:

plusy: szybki rozwój, nie wymagają wiele kodowania i wiedzy. Dobry dla małych aplikacji, które nie zostaną zmienione w przyszłości.

cons: łamie logikę projektowania aplikacji warstwy (tutaj wszystkie zalety takiego projektu) łącząc wszystko w jednym pliku. W rezultacie prawie niemożliwe jest zastąpienie źródła danych dynamicznie. Bardziej skomplikowana obsługa dużych aplikacji. DI, TDD - to coś tajemniczego z niego korzysta.

Właściwie to bardzo szerokie pytanie. Polecam przeczytać więcej na temat tworzenia aplikacji N-warstwowej i Rozwoju Test Driven

nadzieję, że to pomaga

Answer 3

Osobiście uważam, jesteś zdecydowanie na Właściwy tor, ALE imho to naprawdę zależy od tego, co już masz i jakie są plany na przyszłość produktu.

Widziałem kod produkcyjny, który używa dokładnie tak, jak mówisz i działa dobrze, i jest w pewnym stopniu łatwy w utrzymaniu. Istnieje nawet kilka ogromnych spadków modułów od bardzo dużych firm, takich jak Telerik, które należą do tej samej kategorii rozwoju, o której mówisz.

Myślę, że to, co naprawdę jest ważnym czynnikiem dla twojego pracodawcy, to: co możesz zrobić, aby wykonać pracę w najszybszy i najbardziej efektywny sposób. Powiedziałbym jednak, że ogólnie rzecz biorąc, narzędzia "przeciągnij i upuść" po wyjęciu z pudełka nie są zbyt dobre dla długoterminowych aplikacji dla przedsiębiorstw.

Oto artykuł Charlesa Petzolda, który może dostarczyć bardziej "eksperckich" danych uwierzytelniających.

http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html

Answer 4

nie będę nawet iść tak daleko, aby powiedzieć, że projektant elementy DB są dobre dla antykoncepcji progestagenowej lub prototypów. Te komponenty są w Visual Studio przede wszystkim jako platforma sprzedażowa dla frameworka, tak że Microsoft może powiedzieć "wow, zobacz, jak łatwo jest stworzyć aplikację opartą na danych z .NET!" Powinny zostać usunięte lata temu, IMHO.

Nie należy jednak mylić komponentów projektanta z ADO.NET (np. DataTables, DataSet, DataReaders, DataAdapters itp.). Ponieważ odziedziczona aplikacja została zbudowana wokół komponentów projektanta, oznacza to, że była ona zbudowana zasadniczo wokół komponentów ADO.NET. Możesz (i powinieneś) pozbyć się komponentów projektanta, ale nie powinieneś koniecznie pozbywać się ADO.NET.