Conceptul de design Model-View-Controller, în documentaţia de specialitate folosit şi sub forma scurtă de MVC, a apărut ca o necesitate de a transpune metodele tradiţionale de gestionare a datelor în mediul "virtual", mai exact a apărut in scopul de a uşura modul de lucru al utilizatorilor respectând aceleaşi principii de bază şi diferenţiindu-prin instrumentele folosite. MVC a fost mai întâi întâlnit la limbajul Smalltalk dar a fost folosit pe scară largă ani mulţi de-a rândul suferind mai multe redefiniri. Totuşi principiile de baza ale conceptului sunt uşor de înţeles, în schimb detalierile sunt îndeajuns de complexe încât să lanseze multe dezbateri şi să se întâlnească implementări contradictorii.
Principiul care stă la baza conceptului Model-View-Controller este împărţirea responsabilităţilor.
Într-o aplicaţie bazată creată astfel încât să respecte acest concept, partea de model va lucra doar cu starea aplicaţiei şi cu logica ei, nu va conta cum este sau va fi reprezentată această stare către utilizator sau cum interacţionează acesta cu aplicaţia. Tot aşa, partea de "view", este preocupată doar cu crearea interfeţei utilizator în funcţie de datele şi mai ales a schimbărilor stărilor acesteia, recepţionate de la "model". Pentru ea nu contează logica aplicaţiei sau cum are loc procesul de "input", ci doar reprezentarea cât mai corectă a stării curente a modelului. Şi în final, "controller"-ul se ocupă cum translatarea acţiunilor prestate de utilizator în "update"-uri către model, nefiind important la ce va folosi modelul aceste "update"-uri.
Astfel, avem următoarea corespondenţă:
Introducere → Procesare → Rezultat
Controller → Model → View
Încercând să intrăm mai în detaliu, avem acţionarea utilizatorului, modelarea lumii reale, şi răspunsul vizual al sistemului către utilizator sunt separate şi controlate de obiectele "model", "viewport" şi "controller". O vedere pe scurt a ordinii sub care are loc comunicarea între obiecte se poate face astfel: "controller"-ul interpretează semnalele introduse cu ajutorul "Mouse"-ului şi al tastaturii de către utilizator şi furnizează mai departe (ca rezultat) nişte comenzi care sunt trimise către "model" sau/"viewport" pentru a se putea efectua schimbările necesare. "Modelul" gestionează unul, sau mai multe, elemente ale unei surse de date, furnizând atât un răspuns cu situaţia, starea, exactă a sistemului, cât şi posibilitatea de a schimba această stare. Şi nu în ultimul rând "viewport"-ul este partea vizuală pentru utilizator a aplicaţiei, este gestionarul modului sub care sunt prezentate datele utilizatorului utilizând totodată o parte grafică şi/sau o vizualizare sub formă doar de text.
"Model"-ul este utilizat la organizarea informaţiei şi anunţarea când aceasta se modifică. El conţine doar date şi funcţionalităţi care sunt legate printr-un scop comun. Dacă ar fi fost cazul de a modela date din două grupuri care nu sunt legate intre ele, s-ar fi creat două modele separate.
Un model va conţine mai mult decât date şi funcţii care operează pe aceste date. Scopul unui model este de a realiza o aproximare, sau abstractizare, în mediul informaţional al unor procese sau sisteme din lumea reală. El nu trebuie să se limiteze la a captura starea unui preces sau sistem, ci chiar la cum acel sistem funcţionează, ceea ce face foarte uşoară folosirea modelării din lumea reală la definirea propriilor sisteme.
"View"-ul este responsabil de legarea elementelor grafice unui element hardware. De obicei un "view" are o corespondenţă unu-la-unu cu suprafaţa unui "display"şi ştie cum să o folosească. De fapt un "view" se leagă de un "model" şi ne înfăţişează conţinutul lui pe un "display", chiar mai mult, când modelul se va modifica, "view"-ul în mod automat va redesena partea afectată a imaginii pentru a se vedea acele schimbări. Se pot adăuga mai multe modele de "view" la acelaşi model, şi fiecare din aceste "view"-uri redau bucăţi din model pe display-uri diferite.
Separarea codului ce stă la baza unei aplicaţii în cele trei componente ale conceptului MVC va aduce următoarele beneficii directe:
. Permite mai multe reprezentări (views) ale aceeaşi informaţii (model)
. Permite interfeţelor utilizator (views) să fie uşor adăugate, înlăturate sau modificate, în ambele faze, compilare sau/şi execuţie
. Permite uşoara modificare a răspunsurilor la "input"-urile utilizatorului (controller) atât în timpul compilării cât şi în timpul execuţiei
. Promovează reutilizarea (Exemplu: o vizualizare (view) poate fi folosită împreună cu modele diferite)
. Permite mai multor dezvoltători să actualizeze simultan interfaţa, logica sau "input"-ul unei aplicaţii fără a afecta celălalt cod sursă
. Ajută dezvoltătorii să se orienteze, la un moment dat, doar pe un singur aspect al aplicaţiei
În ciuda beneficiilor prezentate în rândurile de mai sus acest concept nu se pretează la toate aplicaţiile, el se adresează mai mult aplicaţiilor de anvergură decât celor mici.
O noţiune nouă care atrage atenţia este cea de "composite viewport" adică un view ce conţine la rândul lui mai multe "sub-view"-uri, şi care la rândul lor pot conţine alte "sub-view". De exemplu în cadrul unui proiect acest model de programare se poate implementa pornind de la nivelul unui singur element al interfeţei utilizator (cum ar fi simplu buton de comandă), la nivelul unui group de elemente ale interfeţei utilizator (cum ar fi un panou de comandă), sau la nivelul întregii aplicaţii.
Comunicarea în cadrul MVC
Deşi părţile "model", "view"şi "controller" în cadrul modelului "Model-View-Controller" sunt intenţionat despărţite, între ele trebuie să existe o comunicare regulată. Partea de modelul trebuie să anunţe modificările de stare părţii de view. Partea de view trebuie să pregătească partea de controller pentru recepţionarea de evenimente de la utilizator şi, posibil, să solicite date de la partea de model. Partea de controller trebuie să facă actualizării ale părţii de model, şi posibil, să înprospăteze partea de view ca răspuns la evenimentele generate de utilizator.
Pentru a facilita această comunicare, fiecare obiect al MVC trebuie să păstreze o referinţă către celălalt(e) obiect(e) cu care interacţionează. Concret, instanţa model are nevoie de o referinţă care foloseşte instanţei view la crearea reprezentării modelului, în timp ce părţile de view şi controller au nevoie fiecare de o referinţă la model şi referinţe reciproce, una către cealaltă. Figura 1, de mai jos, ne arată mai exact cum obiectele din MFC referenţiază una către cealaltă. Forma de diamant din cadrul figurii reprezintă o relaţie de compunere, în cadrul căreia un obiect conţine o referinţa a altuia.
Fig.1 Referinţele obiectelor în MFC
Comunicare porneşte într-o singură direcţie (după cum se poate observa în figura 2) parcurgând obiectele prezentate în figura 1 după cum urmează:
1. Parte de view primeşte evenimente de la utilizator pe care le transmite mai departe spre partea de controller
2. Partea de controller primeşte evenimentele de la utilizator prin partea de view
3. Partea de controller modifică partea de model în raport direct cu răspunsurile de la utilizator (sau,în unele cazuri, partea de controller modifică direct partea de view şi numai actualizează partea de model deloc)
4. Partea de model se modifică în urma "update"-urilor de la partea de controller
5. Partea de model anunţă parţii de view modificările
6. Partea de view actualizează interfaţa utilizator( de exemplu o anume aranjare sau o retrasare a interfeţei, sau se poate chiar prin emiterea unui sunet).
Figura 2 prezintă ciclul de comunicare al conceptului Model-View-Controller. Punctul de pornire al ciclului este de obicei recepţia unui eveniment de la utilizator. Totuşi, o altă parte a programului ar putea să pornească ciclul prin modificarea părţii de model în mod direct (posibil în urma unor date noi care sosesc dinspre server).
Fig.2 Ciclu de comunicaţie în cadrul MFC
În figura de mai sus este reprezentat cel mai simplu caz de MFC, cu un singur "model", un singur "view", şi un singur "controller". Este des întâlnit ca o aplicaţie să folosească doua sau mai multe vederi (views) pentru un singur model.
În timp ce o implementare folosind modelul MVC poate să conţină mai multe "view"-uri la un model, fiecare view are exact un controller şi reciproc. Fiecare "controller" este dedicat servind doar acel "view". În concluzie am putea spune că partea de "view" şi partea de "controller" formează o pereche indivizibilă. MVC cere ca fiecare "view" să aibă un "controller" (chiar dacă acesta are valoare fixă, sau nulă) şi fiecare parte de "controller" are o parte de "view".
În cazul unor aplicaţii partea de "view" nu permite modificări din parte utilizatorului. De exemplu, o proiectare (view) a stării modelului să se facă prin intermediul unui grafic ce nu permite editare. Când avem o astfel de proiectare care nu acceptă modificări de la utilizator, nu este nevoie de un "controller" care să transpună modificările făcute de utlizator în actualizări ale părţii de model. De aceea, vederile ce nu acceptă intrări din partea utilizatorului vor folosi fie "nul" în locul "controller"-ului , fie un "controller" ce nu va face nimic în urma intrărilor.
Rolurile componentelor modelului MVC
După cum am spus şi în rândurile de mai sus, responsabilităţile în cadrul unei implementării de tip Model-View-Controller sunt împărţite, în mod normal, între cele parţi componente model, vedere (view) şi controlor (controller). O descriere pe scurt a responsabilităţilor ar fi " modelul organizează datele şi parte de logică, vederea crează interfaţa, şi controlorul procesează "intrările" utilizatorului". Fiecare astfel de responsabilitate este împărţită în mai multe "task"-uri specifice, care vor fi acoperite în cele ce urmează.
Rolurile părţii de model
Partea de model înmagazinează datele sub formă de proprietăţi şi pune la dispoziţie metode specifice aplicaţiei care permit extragerea şi fixarea datelor. Metodele care gestionează datele nu sunt ceva generic, ele sunt adaptate cerinţelor aplicaţiei şi trebuie să fie cunoscute parţilor de control şi de vedere.
Datele din cadrul parţii de model pot fi modificate extern de către o clasă externă sau intern ca urmare a logicii proprii. Partea de model trebuie să pună la dispoziţie o modalitate prin care vederile să fie înregistreze sau să iasă din evidenţă singure, şi modelul să organizeze o listă a vederilor înregistrate. De fiecare dată când modelul observă o schimbare importantă a propriei stării, trebuie să anunţe toate vederile înregistrate.
În final, modelul este acela care implementează partea logică a "triadei" MVC. De asemenea el furnizează şi servicii de validare a datelor şi alte utilităţii specifice aplicaţiei.
Rolurile părţii de View
Vederea (View) trebuie să creeze interfaţa utilizator după care trebuie să o ţină la curent. Vederea urmăreşte stările modelului; când modelul suferă modificări, vederea îşi actualizează interfaţa astfel încât să reflecte această schimbare. Fiecare vedere trebuie să dea mai departe toate evenimentele legate de intrările de informaţii controlorului propriu. Nu trebuie să proceseze nici o intrare de una singură.
În funcţie de specificul implementării, partea de vedere poate să ceară părţii de model informaţii despre starea lui cu scopul de a afla ce s-a schimbat în momentul în care este primită o actualizare. Partea de vedere nu va face schimbări în model niciodată, dar poate extrage informaţii de la el. Comunicarea dintre model şi vedere este de tip push-pull, fie vederea extrage, solicită, starea modelului la un moment dat, o comunicare de tip pull, fie modelul "împinge" starea proprie către vedere în momentul unei schimbării importante a propriei stări.
În urma descrierii de până acuma se poate ridica următoarea întrebare, "Are sens modelul de design Model-View-Controller din punct de vedere arhitectural. Poate să pară neobişnuit, chiar ciudat, ca dacă utilizatorul modifică ceva pe vedere, în loc să răspundă imediat, vederea trimite modificarea mai departe către controlor, care la rândul lui o trimite mai departe la model care anunţă vederii schimbarea, şi care în final, vederea cere modelului detalii legate de modificare pe care după aceea le prezintă utilizatorului. Nu ar fi mult mai simplu să se treacă peste această comunicare complicată şi să avem o proprie actualizare a vederii de fiecare dată când utilizatorul face o modificare? Într-o anumită măsură este mai uşor, şi pentru o aplicaţie mai simplă s-ar putea ca o astfel de soluţie să fie mai adecvată. Cu cât o aplicţie devine mai complexă, cu atât modelul MVC oferă beneficii mai semnificative.
Rolurile părţii de Controller
Controlorul aşteaptă anunţarea de evenimente din partea părţii de vedere ca urmare a unor modificări realizate de utilizator şi să le transpună în modificări pentru model. În unele cazuri speciale, controlorul ar putea să inducă modificări părţii de vedere prin apelarea de metode din cadrul vederii. Modificările sunt trimise direct vederii doar în cazul în care sunt doar de cosmetizare a vederii şi nu au nici un efect asupra modelului (de exemplu funcţiile de ordonare de liste).
Microsoft SQL Server 2005
Introducere to sql
SQL acronim pentru Structured Query Language reprezintă una din temeliile fundamentale ale arhitecturii moderne a bazelor de date. În cadrul "limbajului" SQL apar definite metodele folosite la crearea şi manipularea bazelor de date relaţionale pe toate marile platforme. La o primă vedere, limbajul poate fi intimidant şi complex dar nu este chiar aşa.
S-ar putea să fi auzit acronimul SQL pronunţat în diferite forme, oficial, American National Standards Institute (pe scurt ANSI), a declarat ca pronunţie oficială "es queue el", cu toate acestea, mulţi din profesioniştii IT folosesc pronunţarea în argou "sequel".
Puteţi întâlni limbajul SQL sub multe forme, astfel Oracle foloseşte propria versiune brevetată PL/SQL. La Microsoft SQL Server este folosit sub numele de Transact-SQL. Cu toate aceste variante sub care apare, toate au la bază standardul ANSI SQL.
Limbajul SQL poate fi împărţit în două sub-limbaje. Data Definition Language (DDL), mai pe româneşte spus limbajul folosit la definirea datelor, care conţine comenzile folosite în crearea şi distrugerea bazelor de date, precum şi a obiectelor acestora. După ce structura bazelor de date a fost definită cu ajutorul DLL, administratorii bazelor de date şi utilizatorii folosesc Data Manipulation Language (DML) la inserarea, obţinerea şi modificarea datelor conţinute în ele. Astfel pentru a nu insista prea mult asupra detaliilor de implementare legate de folosirea SQL voi trece totuşi în revistă câteva comenzi şi cum acţionează ele asupra bazei de date spre a sublinia diferenţele dintre cele două sublimbaje, Data Definition Language, şi respectiv, Manipulation Language.
Din comenzile aparţinând Data Definition Language (DDL) enumăr următoarele:
. CREATE - se foloseşte la crearea unei baze de date în cadrul căreia se vor crea mai apoi tabele şi abia în acestea din urmă se vor introduce datele;
. USE - având în vedere că de obicei pe o platformă avem mai multe baze de date, comanda "use" ne ajutăm să alegem una dintre ele pe care vom opera mai departe;
. ALTER - este comanda care ne permite modificarea structurii bazei de date;
. DROP - după cum era de aşteptat, "alter" este comanda cu ajutorul căreia distrugem o bază de date.
Din comenzile aparţinând Data Manipulation Language (DML) enumerăm:
. INSERT - este comanda folosită pentru a adăuga date în câmpurile structurii bazei de date deja create;
. SELECT - este comanda cel mai des folosită de utilizatorii SQL, fiindcă este comanda folosită la căutarea şi extragerea de informaţii, date, care au fost deja introduse în baza de date;
. UPDATE - este comanda folosită pentru a modifica date din baza de date;
. DELETE - după cum îi spune şi numele este comanda folosită la ştergerea de informaţii din câmpurile bazei de date.
Această enumerare de comenzi SQL nu se poate termina fără a aminti comanda JOIN. JOIN este comanda care permite crearea de legăturii între mai multe baze de date, şi după unii, este comanda care dă adevărata putere limbajului SQL.
Microsoft SQL Server 2005
Introducere
În ziua de astăzi organizaţiile se confruntă cu numeroase provocări în ceea ce priveşte datele, de exemplu necesitatea unor decizii mai rapide şi mai avizate, necesitatea creşterii productivităţii şi flexibilităţii personalului responsabil cu dezvoltarea şi presiunea de a reduce bugetele IT generale simultan cu scalarea infrastructurii pentru a satisface cererile în continuă creştere.
Următoarea versiune a Microsoft SQL Server este concepută pentru a ajuta întreprinderile să abordeze aceste provocări. Microsoft SQL Server 2005 este soluţia Microsoft de generaţie următoare pentru managementul şi analiza datelor, care oferă securitate, scalabilitate şi disponibilitate crescute pentru datele întreprinderii şi aplicaţiile analitice, făcând crearea, implementarea şi managementul acestora mai facile.
Generat având la bază SQL Server 2000, SQL Server 2005 oferă o soluţie integrată de management şi analiză a datelor ,care va ajuta organizaţiile de orice dimensiune să:
. Dezvolte, implementeze şi administreze aplicaţii la nivel de întreprindere mai sigure, scalabile şi fiabile;
. Maximizeze productivitatea IT prin reducerea complexităţii creării, implementării şi administrării aplicaţiilor pentru baze de date.
. Partajeze date pe mai multe platforme, aplicaţii şi dispozitive pentru a facilita conectarea sistemelor interne şi externe.
. Controleze costurile fără a sacrifica performanţa, disponibilitatea, scalabilitatea sau securitatea
Ce este Microsoft SQL Server 2005?
Microsoft SQL Server 2005 este o platformă cuprinzătoare pentru baze de date care pune la dispoziţie instrumente de gestiune a datelor la nivel de clasă enterprise cu integrare de instrumente de "business intelligence" (BI). "Engine"-ul care stă la baza platformei SQL Server 2005 este cel mai sigur şi mai de încredere loc de stocare atât pentru datele de tip structural cât şi de tip relaţional, permiţând astfel crearea şi administrarea de aplicaţii de date extrem de folositoare şi performante pe care utilizatorii şi administratorii să le folosească spre progresul afacerii.
Motorul SQL Server 2005 stă la baza soluţiilor de management al datelor la nivel enterprise. Suplimentar, SQL Server 2005 oferă ceea ce este mai bun pe parte de analiză, creare de rapoarte, integrare Microsoft şi avertizare. Ceea ce oferă unei echipe de dezvoltători să creeze şi să implementeze soluţii ieftine de BI (business intelligence) cu ajutorul cărora să adune şi/să furnizeze informaţii în orice colţişor al firmei cu ajutorul graficelor, serviciilor Web şi serviciilor mobile.
Integrarea strânsă cu celelalte tehnologii Microsoft cum sunt Microsoft Visual Studio, Microsoft Office System, şi o suită de noi instrumente pentru dezvoltare, care include Business Intelligence Development Studio, fac ca SQL server să fie ceva deosebit. Indiferent dacă eşti un dezvoltator, administrator de baze de date, utilizator al datelor (informaţiei), sau factor de decizie, SQL Server 2005 îţi pune la dispoziţie cele mai inovative soluţii care să te ajute să dai valoare cât mai mare informaţiilor tale.
Următoarea diagramă ilustrează componentele de bază ale SQL Server 2005, subliniind cum SQL Server 2005 este o componentă cheie a Windows Server System integrându-se pe platforma Microsoft Windows, care cuprinde Microsoft Office System şi Visual Studio pentru a oferi soluţii care să permită informaţiei să ajungă în fiecare colţ al firmei.
SQL Server 2005 vine în ajutorul celor care îl folosesc prin trei viziuni diferite, în funcţie de cei care îl folosesc, şi avem:
. Enterprise Data Management - SQL Server 2005 pune la dispoziţie platforma cea mai practică, sigură (în sensul de securizată) şi productivă atât pentru creare de aplicaţii de business cât şi pentru aplicaţii analitice
. Developer Productivity - SQL Server 2005 oferă un mediu de dezvoltare "end-to-end" ce include tehnologii noi ce ajută dezvoltătorii şi astfel le creşte productivitatea.
. Business Intelligence - prin oferirea unui mediu care poate cuprinde cantităţi mari de date, integrare cu alte produse, şi capacitatea de migrare a datelor face posibil ca firmele să-şi permită sporirea valorii aplicaţiilor. Soluţiile BI având la bază SQL Server 2005 pune informaţiile critice, sau în criză de timp, la îndemâna tuturor utilizatorilor, permiţându-le astfel să ia deciziile mai bune mult mai repede.
proceduri stocate
Un instrument pus la dispoziţie de platforma SQL Server 2005 (există şi în variante anterioare), îl reprezintă aşa numitele proceduri stocate. Procedurile stocate au fost create de cei de la Microsoft în scopul de a simplifica procesul de dezvoltare a bazelor de date prin gruparea de comenzi Transact-SQL în blocuri care pot fi parametrizate.
Procedurile stocate sunt foarte similare constructorilor întâlniţi în alte limbaje de programare. Ele acceptă date sub formă de parametri de intrare, care sunt specificaţi în momentul execuţie. Aceşti parametri (dacă sunt implementaţi) sunt folosiţi la execuţia de comenzi SQL care creează un rezultat. Aceste rezultate sunt returnate mediului care le-a apelat cu ajutorul unor înregistrări, variabile de ieşire sau cod de ieşire. Poate părea complicat dar prin utilizare s-au dovedit adesea uşor de înţeles şi folosit de către dezvoltători.
Printre beneficiile folosirii de proceduri stocate sunt:
. Serverul SQL compilează fiecare procedură o singură dată iar apoi o apelează în mod repetat sporind performanţele serverului;
. Reduce traficul client/server ceea ce înseamnă reducerea costurilor traficului de reţea;
. Folosirea codului într-un mod mai eficient astfel procedurile stocate pot fi folosite de mai mulţi utilizatori sau programe client;
. Creşterea securităţii prin posibilitatea de acordare de drepturi la nivel de procedură stocată.
.
Visual Studio 2005
Visual Studio este definit de către Wikipedia ca fiind un mediu avansat de dezvoltare integrată produs de Microsoft care permite programatorilor să creeze programe, site-uri web, aplicaţii web, şi servicii web care se pot rula pe Microsoft Windows, PocketPC, Samrtphones, şi pe întregul internet.
Dintre mediile de programare pe care le întâlnim în cadrul Visual Studio amintesc următoarele: Visual Basic, Visual C++, Visual C#, Visual J#. Visual Studio apare, în calitate de produs Microsoft, în diferite variante şi la diferite preţuri, ceea ce face ca componentele care fac parte din variante diferite să difere şi ele la rândul lor. Tipul şi numărul componentelor diferă şi de la o variantă la alta in funcţie de momentul lansării (urmează o scurtă istorie).
Visual Studio History
În ziua de azi, Visual Studio 2005, se poate descrie în două cuvinte: productivitate personalizată. Această descriere se poate uşor dezvolta rezultând o nouă definiţie: Visual Studio 2005 este un mediu, o platformă, de dezvoltare ce oferă instrumente de dezvoltare, adresându-se unei mase mari de persoane cu nivele diferite de pregătire, astfel de la tineri programatori şi studenţi, la echipe mici şi medii de dezvoltători, la consultanţi IT şi completând imaginea cu organizaţii mari în care se dezvoltă aplicaţii software, şi cu ajutorul căruia se abordează mai bine întreg ciclul de viaţă al unui produs software.
În rândurile următoare se încearcă o rememorare a momentelor de cotitură din dezvoltarea acestei tehnologii, astfel avem:
Visual Studio 97
În 1997 are loc prima lansare a produsului Visual Studio. La acel moment se prezenta sub forma unei pachet ce aduna împreună mai multe instrumente folosite la crearea programelor. La acel moment Visual Studio cuprindea Visual Basic 5.0 , Visual C++ şi Visual J++ pentru programarea sub Windows şi Visual FoxPro 5.0 la programarea de tip xBase. Tot la această lansare este introdus şi modulul Visual InterDev folosit la crearea de situri web folosind Active Server Pages.
Tot în cadrul produsului lansat în 1997 se încearcă folosirea aceluiaşi model de mediu de dezvoltare pentru limbaje diferite. C++,J++. InterDev, şi MSDN Library foloseau toate un singur mediu numit Developer Studio. Visual Basic şi Visual FoxPro vor continua să folosească medii proprii.
Visual Studio 6.0
Varianta următoare apare imediat după aceea, chiar în anul următor, adică 1998. Toate componentele mediului au trecut la versiunea 6.0 (inclusiv J++ care a sărit de la versiunea 1.1. Această versiune va sta la baza tuturor implementărilor pentru următorii patru ani, dezvoltătorii de la Microsoft muncind la ceea ce se va numi .NET Framework.
Dintre celelalte caracteristici ale acestei variante mai amintim că este ultima variantă în care vom întâlni Visual Basic, limbaj de programare ce avea ala acel moment numeroşi "adepţi". În urma procesului pierdut de Microsoft în faţa Sun, Microsoft se vede nevoit să numai pună în vânzare instrumente de programare adresate Java Virtual Machine.
Visual Studio .NET
Microsoft lansează pe piaţa IT în 2002 un nou produs adresat dezvoltătorilor de aplicaţii software, şi anume, Visual Studio .NET, care aduce mai multe noutăţi dintre care remarcăm introducerea unui mediu de dezvoltare care să gestioneze codul, acest mediu este bazat pe tehnologia .NET Framework. Noile programe dezvoltate în acest mediu nu mai sunt compilate în limbaj maşină (cum era cazul în C++ de exemplu) ci într-un format nou numit MIL.
Când se execută o aplicaţie folosind MIL, compilarea se face în timpul execuţiei în limbajul maşină al platformei pe care este executat, ceea ce face ca aplicaţia să fie portabilă pe mai multe platforme, totuşi pentru executarea acestui tip de aplicaţii compilate în MIL platforma trebuie să aibă implementat "Common Language Infrastructure". Deci este posibil să rulăm aplicaţii de tip MIL sub Linux sau Mac OS X folosind implementări ale .NET independente de Microsoft cum sunt Mono şi DotGNU.
Tot în această versiune de Visual Studio, Microsoft introduce un nou limbaj de programare similar cu Java care foloseşte platforma .NET, numit C#. Tot acum este introdus şi urmaşul lui Visual J++ numit Visual J# care foloseşte sintaxa limbajului Java.
Visual Studio .NET poate fi folosit la crearea de aplicaţii spre folosirea sub Windows (Windows Forms, parte a .NET Framework), în spaţiul Web (prin folosirea ASP.NET si Web Services) şi, cu ajutorul unui add-in pe dispozitivele portabile (folosind .NET Compact Framework).
Visual Studio .NET 2003
Visual Studio .NET 2003 aduce mici înbunătăţirii variantei din 2002, şi anume, face trecerea la folosirea .NET Famework 1.1, vine direct integrat cu suportul pentru dispozitivele mobile care folosesc fie ASP.NET, fie .NET Compact Frameworks.
