October 2007 - Príspevky
Nové Visual Studio 2008 je na spadnutie a tak si dovolím urobiť základný prehľad rozdielov medzi jeho edíciami Express->Standard->Professional. Za základnú čiaru považujme VS 2008 Express Studio, kde pribudne CSS dizajnér, ASP.NET AJAX podpora, LINQ podpora...
VS 2008 Standard bude mať v porovnaní s Express edíciou naviac:
- XAML dizajnér podporujúci "split" editovanie
- plnú podporu WCF vrátane test.klienta a nástrojov pre autohosting
- dizajnér pre Workflow Foundation
- plnú podporu pre výber cieľového .NET Framework-u (2.0, 3.0 alebo 3.5)
- databázové dizajnéry ( tvorba, úprava tabuliek a SP) aj pre vzdialené databázy
- editor nielen pre XML ale aj pre XSLT
- možnosť tvorby inštalačných MSI balíčkov
- remote debugging
VS 2008 Professional bude mať v porovnaní s Standard edíciou naviac:
- šablóny pre tvorbu Office projektov ( pre MS Office 2003 a 2007 ), aj šablónu pre Sharepoint Workflow (, čiže nový Profesional už bude obsahovať celú sadu Visual Studio Tools for Office)
- podporu pre tvorbu mobilných aplikácií
- MSDN na inštalovateľných médiach
- Class Designer
- Crystal Reports aj Reporting Services
- "Servers" uzol v Server Explorer-e
- Unit Testing
- SQL Server 2005 Developer Edition
Minoritných rozdielov je samozrejme viac, ale ak tým niekto moc nezatrasie, v takejto podobe budú "netímové" edície uvedené na trh v druhej polovici novembra.
Miro
Pre získavanie dát do separátnych HTML "controlov" pre javascript na strane klienta uprednostňujem (pre ich komunikačnú štíhlosť) webové služby/JSON. Dajú sa naviac použiť vo viacerých stránkach/aplikáciach bez nutnosti ich "pribaľovania" ku konkrétnej aplikácii.
Občas sa ale vyskytne situácia, keď budete potrebovať rýchlo vytvoriť skelet volaní "AJAX klient<->webová metóda" bez tvorby webovej služby. ASP.NET Ajax podporuje špeciálne typy webových metód s označením "page method". Ide vlastne o webové metódy priamo v .NET kóde na pozadí "aspx" stránok. Musia byť "public static" a deklarované minimálne atribútom
"WebMethod". Na klientovi je treba nastaviť elementu "ScriptManager" atribút "EnablePageMethods" na hodnotu "true" (, aby sa pre klienta generovala vrstva PageMethods proxy).
V mojom prípade som potreboval na jednej stránke dostať na klienta asynchrónnym volaním XMLHTTP číslo účtu, ktoré mal užívateľ uložené v Session. Tu je postup krokov, ktoré som použil:
1. Do časti referencovania namespacov kódu na pozadí "aspx" stránky som pridal:
using System.Web.Services;
using System.Web.Script.Services;
2. Do kódu triedy na pozadí stránky "aspx" som pridal "page method" volateľnú priamo z AJAX klienta:
[ScriptMethod]
[WebMethod]
public static string vratDefaultUcet()
{
return (string)HttpContext.Current.Session["prednastavenyUcet"];
}
3. Do deklarácie ScriptManager-a HTML zdroja stránky "aspx" som pridal atribút "EnablePageMethods":
<asp:ScriptManager ID="ScriptManager1" runat="server" EnablePageMethods ="true">
</asp:ScriptManager>
4. HTML zdroj stránky "aspx" obsahoval tlačidlo, ktoré po "onClick" zavolalo javascriptovú funkciu "zistiDefaultUcet". Jej hlavnou úlohou bolo cez XMLHTTP zavolať "PageMethod" servera a výsledok pomocou callback funkcie vypísať v HTML prvku s ID "Ucet":
<script type="text/javascript">
function zistiDefaultUcet()
{
PageMethods.vratDefaultUcet(AkToServerVrati);
}
function AkToServerVrati(vysledok)
{
var ucet = document.getElementById("Ucet");
ucet.innerHTML = vysledok;
}
</script>
Snáď sa vám to niekedy zíde.
Miro
UpdatePanel predstavuje extrémne rýchly spôsob, ako sa zbaviť "preblikávania" stránok pri odosielaní dát z "aspx" stránok na server. Stačí (logicky) samostatne aktualizovateľné skupiny ovládacích prvkov na stránke povkladať do "kontajnera" typu UpdatePanel. Na častiach stránky sa tak vykonáva AJAX callback, ktorý prenáša na/z servera len to potrebné pre čiastočnú aktualizáciu stránky.
A tu sa v glorifikovaní a zahmlievaní UpdatePanel-a zastavme:
- Odstránenie prebliknutia stránky nasadením UpdatePanel-a zákonite neznamená zvýšenie efektivity pri prenose dát. Množstvo dát odosielaných z UpdatePanel-a na server je zhruba na úrovni plného postback-u, čiže vrátane viewstate dát stránky a iných dát zo stránky. Čiže UpdatePanel je hlavne o jednoduchosti použitia (=vytvorení asynchrónnej XML-HTTP požiadavky), nie o výraznom odľahčení prenosového kanála.
Môžete si to jednoducho overiť aj sami v typickom príklade, keď máte na stránke položku PSČ, tlačidlo "ZistiMesto" a iný "textbox", do ktorého chcete asynchrónne vkladať mesto zodpovedajúce zadanému PSČ. Vložte takúto časť stránky do jedného UpdatePanel-a. Užívateľovi pribudne pocit svižnosti ( spôsobenej asynchrónnou komunikáciou so serverom), ale množstvo prenášaných dát na server sa prakticky nezmení. Spracovanie na strane servera totiž pre "zbehnutie" celého cyklu udalostí stránky vyžaduje všetky potrebné dáta stránky vrátane viewstate atď.
Práve v tomto "PSČ" príklade sa núka iné AJAX riešenie - volanie webovej služby z klientského javascriptu prenosom dáta vo formáte JSON. Vtedy totiž na otázku z javascriptu "vratMesto" pôjde na server jednoduché volanie ( bez viewstate a dát z iných položiek) a naspäť sa asynchrónne vráti jednoduchá JSON štruktúra s požadovanými dátami.
Na záver: Zvážte, či na Vašu situáciu nedokážete "našiť" volanie webovej služby z klientského javascriptu. Ak áno, i keď sa nakódujete viac, výrazne odľahčíte prenosový kanál. Ak nie, použitie UpdatePanel. Na server sa síce bude prenášať takmer rovnaké množstvo dát ako pri plnom "postback-u", ale jeho použitie je prakticky bez dodatočného kódovania a na stranu klienta sa zo servera vráti naozaj tenšia odpoveď (v porovnaní s odozvou pri plnom postback-u).
Miro
LINQ to SQL patrí medzi jednu z hlavných noviniek .NET Framework-u 3.5. Jeho základom je behové prostredie pre riadenie relačných dát vo forme objektov bez straty podpory "query" jazyka. Aplikácia manipuluje s objektami ( čo je pre objektovo orientované .NET jazyky prirodzenejšie), kým "LINQ to SQL" na pozadí má na starosti automatické "trekovanie" zmien v databáze. Previazanie medzi objektami aplikácie a reálnymi tabuľkami databázy je deklarované tzv. ORM diagramom ("object relational mapping"). V VS2008 sa dá ORM model vytvoriť jednoducho v "LINQ to SQL" dizajnére.
A tu vyvstvávajú otázky: Je možné držať ORM mapovanie v nejakom externom súbore a tým sa vyhnúť pri zmene štruktúry tabuľky rekompilácii aplikácie ? Skrývajú sa v tom nejaké úskalia ?
Odpoveď 1: LINQ to SQL podporuje externé mapovanie uložené v súbore. Mapovací XML súbor tak podporuje scenáre, kedy je potrebné udržiavať mapovanie mimo aplikačného kódu. (S vytvorením mapovacieho súboru vám môže pomôcť tool SQLMetal, ktorý je v Windows SDK.) Základná trieda LINQ to SQL - DataContext - má konštruktor so špeciálnym argumentom MappingSource pre použitie externého mapovania.
Príklad:
....
String cesta = @"C:\Mapping\MojaDBMapping.xml";
XmlMappingSource tabulkaMapping = XmlMappingSource.FromXml(File.ReadAllText(cesta));
MojaDB db = new MojaDB( @"Server=.\SQLExpress;Database=c:\DB\MojaDB.mdf", tabulkaMapping );
....
viac na http://msdn2.microsoft.com/en-us/library/bb425822.aspx
Odpoveď 2: Linq to SQL implicitne narába s mapovaním cez atribúty ( nie cez externý súbor ). Používa zdroj AttributeMappingSource, v ktorom sú všetky prelinkovania tabuliek a stĺpcov na triedy a vlastnosti uložené ako atribúty objektu DataContext.
Príklad:
....
[Table(Name="dbo.Ciselnik")]
public partial class Ciselnik : INotifyPropertyChanging, INotifyPropertyChanged
.....
Vďaka tomu sa kód číta ľahšie a kompilátor dokáže okamžite zistiť, či je všetko OK. Ak zmeníte implicitný spôsob mapovania na externý XML súbor, získate zasa možnosť meniť mapovanie bez nutnosti rekompilácie, ale na chyby mapovania sa často príde až pri behu aplikácie. Takže, to či preferovať atribútové alebo externé mapovanie je dané požiadavkou, či je alebo nie je potrebné oddeliť mapovanie od aplikačného kódu. Osobne (ak ma k tomu neprinúti vyššia sila 
,) sa skôr prikláňam k atribútovému mapovaniu z dvoch dôvodov - minimalizácia chýb počas runtime, plný komfort dizajnéra v VS2008. ( Predpokladám, že vás aj tak aspoň jeden zákazník časom pritlačí k externému mapovaniu v domnení, že tým aplikácia nabudne novú formu "customizácie" ).
Miro
3.10.2007 oznámil Microsoft, že s uvedením Visual Studia 2008 na trh (na konci tohto roka) sprístupní aj zdrojové kódy väčšiny knižníc .NET Framework-u pod zmluvou Microsoft Reference License. ( Microsoft Reference License umožňuje prezerať zdrojový kód, ale nepovoľuje jeho úpravy a redistribúciu. Detaily nájdete na http://www.microsoft.com/resources/sharedsource/licensingbasics/referencelicense.mspx )
Prakticky to znamená, že ten, kto akceptuje podmienky tejto licencie, bude môcť nahliadnuť do zdrojového kódu väčšej časti .NET Framework-u – Base Class Library ( namespacy System, System.IO, System.Text, System.Collections, System.CodeDom, Regular Expressions atď.), Windows Forms, ASP.NET, ADO.NET (System.Data), XML a WPF. ( V pláne je postupné sprístupnenie aj ďalších častí .NET Framework-u.)
Ako budete prakticky môcť použiť zdrojový kód .NET Framework-u?
- stiahnuť balíček s dostupným zdrojovým kódom a prezerať si ho lokálne
- použiť integráciu do Visual Studia 2008 ( edície Standard a Professional), ktorá umožní debugovať vlastný kód spolu s kódom .NET Framework-u. Visual Studio si pritom symboly pre zdrojový kód dotiahne online z internetového servera.
Viac podrobností nájdete na blogu Scotta Guthrieho http://weblogs.asp.net/scottgu/
Miro
Viac príspevkov