2008-10-28 9 views
6

Przygotowuję klasę na Visual Basic 2005 targetowania programistów Visual Basic 6 migrujących do platformy .NET.Funkcje uruchomieniowe VB w VB.NET dla programistów VB6

Moim głównym problemem jest nauczenie moi studenci najlepszych praktyk dla rozwoju w .NET, a ja zastanawiałem się, czy aby rozważyć zastosowanie funkcji wykonawczych VB VB.NET uzasadniony, czy nie.

Przeczytałem, że wiele funkcji VB w VB.NET faktycznie wywołuje metody w .NET Framework, więc wydaje się, że istnieją przede wszystkim w celu ułatwienia przejścia od wcześniejszych wersji Visual Basic do VB.NET. Jednak wydaje się, że the VB.NET team zaleca się używać ich, gdy tylko jest to możliwe, ponieważ twierdzą, że wprowadzili tam pewne optymalizacje na platformach API platformy .NET.

Co sądzisz o tym?

+1

Zobacz także [ta dyskusja] (http://stackoverflow.com/questions/226517/is-the-microsoft-visualbasic-namespace-true-net-code) – MarkJ

Odpowiedz

7

gdzie jestem, muszę poruszać się tam iz powrotem między C# i VB.NET często. Mając to na uwadze, naprawdę nie lubimy starych funkcji VB, zwłaszcza funkcji łańcuchów: Trim(), Replace(), Len(), UCase(), itp. Po prostu wyglądają dziwnie w programie .Net i nie chciałbym ich widzieć w kodzie, który musiałem pracować na.

Jedynym wyjątkiem może być Len(), jeśli czytasz kod w swojej głowie, używając rubryki of. W takim przypadku czytanie Len(theString) jako wydaje się mieć sens. W innych jest to bardziej operacja wykonywana przez ciąg, więc chcę zobaczyć. (kropka) notacja.

Z drugiej strony, miałem trudny czas odzwyczajania się od operatorów konwersji: CStr, CInt, CDbl, itp

Nie mogę powiedzieć, dlaczego ja jak jeden typ, a nie inne; może być tak, że znajduję Convert.To ___() jest zbyt szczegółowe, lub może ma to coś wspólnego z ich funkcjonowaniem, a nie funkcjami.

Edit
Ten punkt trochę zabłądził w pozostałej części mojego postu, więc chcę podkreślić jeszcze raz:

W wielu miejscach, VB.Net współistnieje z C#. Nie sądzę, że widzisz tyle sklepów tylko w VB.Net, ile możesz dla C#. To nie jest tak popularne, a wiele sklepów VB.Net przenosi się do VB.Net w stanie przejściowym, podczas gdy programiści uczą się także języka C#.W tych mieszanych środowiskach ma to wiele sensu, jeśli stare funkcje VB są surowo zabronione w nowym kodzie. Nigdy nie wiadomo, kiedy moduł będzie musiał zostać przeniesiony i istnieje pewne obciążenie związane z umysłem, gdy trzeba mieć możliwość grokowania obu stylów naraz. Więc naprawdę nie jest dobrze, żeby zrozumieć oba.

+2

Nie jestem pewien, co masz na myśli mówiąc, że VB.NET jest "mniej popularny" - ale Lisa Feigenbaum, premier Microsoft w grupie .NET Managed Languages, mówi, że obecnie jest nieco więcej programistów VB.NET niż C#. http://www.infoq.com/news/2009/06/Future-VB.NET – MarkJ

+0

(BTW dałem ci +1!) Kolejny drobny spór. Myślę, że pomaga ci uniknąć klasycznego błędu "niezmienny ciąg", jeśli użyjesz Zamienia (s, "a", "b") zamiast s.Zamień ("a", "b"). Na przykład błąd popełniony przez sholsingera tutaj http://stackoverflow.com/questions/1112553/why-cant-i-ning-replace-on-a-io-file-readalltext-string – MarkJ

+2

Słuchaj, głosowałbym to sto razy, gdybym mógł! Widziałem najbardziej przerażający kod stworzony przez programistów, którzy myślą, że mogą uciec z nieuczęszczaniem VB.NET, ponieważ ich kod VB6 działa. –

-3

Jeśli uczysz VB, te funkcje są częścią VB. Jeśli uczysz .Net Framework, te funkcje nie są częścią Framework. Jeśli próbujesz wykonać swoją pracę i masz dostępne narzędzia, użyj swoich narzędzi.

+3

W rzeczywistości, _jest_ częścią struktury. Możesz nawet użyć ich z C#, jeśli chcesz. –

4

Cóż, myślę, że trzeba wziąć je w wartości nominalnej. Jestem programistą C# głównie, ale pracuję nad aplikacją WWW VB.NET przez ostatnie 6-8 tygodni.

Moja siedziba estymacji spodnie sugeruje, że przy użyciu funkcji konwersji, takich jak CInt, etc cdate się tak szybko jak przy użyciu metod Convert.Toxxx.

Moja rada to: jeśli to sprawia, że ​​łatwiej i nie ma kary wydajność to idź do niego! Chciałbym również nauczyć ich podejścia .NET i pozwolić użytkownikowi zdecydować.

BTW, jak C# facetem, kocham łatwość rutyny Cxxx. Tylko dlatego, że są one dostępne tylko w VB.NET, nie oznacza, że ​​nie powinieneś ich używać (IMHO). Konie na kursy i tak dalej.

+2

Dodaj dyrektywę using dla Microsoft.VisualBasic i możesz z nich korzystać również z C#. –

3

Jeśli chcesz nauczyć się najlepszych praktyk w ramach platformy .Net, które można przenosić w różnych językach, sugeruję usunięcie globalnego importu dla Microsoft.VisualBasic. To zasadniczo zmusza Cię do zrobienia Microsoft.VisualBasic.Trim() itp. Zamiast po prostu "Trim()".

Jeśli się nie mylę, w Visual Studio 2008 można teraz usunąć odniesienie razem dla "czystego" trybu .Net w vb.net, co ułatwia poruszanie się między językami.

Jeśli jesteś tylko uczniem facetów vb.net, jak wyżej wymienione plakaty, użyj ich, ponieważ są one dostępne i wymagają mniej pisania.

4

Jest wiele rzeczy, których programiści VB6 muszą się nauczyć, przechodząc na VB.NET. Dlaczego nie pozwolić im najpierw korzystać z funkcji VB, ale naucz ich wersji platformy .NET. Później mogą przełączyć się na funkcje platformy .NET, szczególnie jeśli prawdopodobnie będą musiały używać C#.

EDYCJA (dużo później): dwaj renomowani guru VB biorą przeciwstawne poglądy!

  • Francesco Balena (w jego popularnej książki Programming Microsoft Visual Basic 2005: The Language) zaleca deweloperzy ex-VB6 nauczyć się składni .NET, gdy tylko czują się komfortowo z nowego języka i unikać używania metod i klas w Microsoft.VisualBasic nazw, jeśli to możliwe [p . 100]. Chodzi o to, że w ogólności natywne metody .NET oferują większą elastyczność, a uczenie się ich jest inwestycją na wypadek, gdyby później trzeba było używać C# lub innego języka .NET.
  • Dan Appleman (w jego popularnej książki Moving to VB.NET: Strategies, Concepts, and Code) zaleca krępuj się trzymać z natywną nazw Microsoft.VisualBasic unikając tylko te w przestrzeni nazw Microsoft.VisualBasic.Compatibility.VB6 [s. 265]. Jego celem jest to, że Microsoft.VisualBasic jest podstawową częścią platformy .NET.
+0

Dzięki za wyróżnienie tych dwóch książek, bardzo interesujące. –

+2

Oba są warte przeczytania, jeśli jesteś programistą VB6, który spóźnia się z .NET. (Na przykład: erm, ja!) Niektóre z treści Dana Applemana nie są poprawne dla najnowszych wersji frameworków, ale jest on tak dobry w wyjaśnianiu przeglądów, że warto go przeczytać. – MarkJ

+1

Świetny komentarz, a punkt Dan Applemana jest bardzo dobry. Przestrzeń nazw + Compatibility + prawdopodobnie powinna być trzymana z dala, chyba że masz po temu bardzo dobre powody. Przestrzeń nazw MS.VisualBasic, OTOH, jest całkowicie uzasadniona do użycia z Iron Python, C# itd. Jest to część Core, a niektóre z funkcjonujących tam funkcji są całkiem przydatne. – DarinH

2

Jedna rzecz, że powinieneś wspomnieć jeśli wspomnieć obie metody ramowe i funkcje VB.NET jest to, że mimo, że czasami czuję się jak są one takie same, mogą one zrobić subtelnie różne rzeczy.

Na przykład, równa operator ciągów traktuje łańcuch pusty tak samo jak String.Empty (zob The real cost of performance na przykład tego, co dzieje się, gdy użytkownik zapomni!)

Również funkcje VB.NET często dają dobrym domyślnym ustawieniem do wykonania danej operacji, ale tam, gdzie potrzebna jest większa kontrola, często trzeba będzie powrócić do metod ramowych - na przykład, jeśli potrzebujesz make string conversions in a different culture.