Valdis Iljuconoks : ASP.NET

Schedule

valdis.iljuconoks — Wed, 18 Apr 2012 21:09:00 GMT

Kā izrādās, tad aprīļa pašas beigas un maija mēnesis izvērties par diezgan aizņemtu laika posmu. Katrā ziņā, var noķert mani kaut kur tur

Aprīlis 2012:

2012.04.26: Transporta un Sakaru Institūts:

18:15 – 19:15 “MSF & Agile”

19:15 – 19:45 “TFS 2012 Overview (Dev ‘11)”.

Maijs 2012:

2012.05.07: Latvijas Universitāte:

18:15 – 19:15 “Parallel Computing in Visual Studio 2010”

2012.05.08: Vidzemes Augstskola:

10:00 – 10:55 “Asp.Net MVC”

11:00 – 11:55 “Funkcionālā programmēšana - F#”

12:00 – 12:55 “Visual Studio 2012 - What's new?”

13:00 – 13:55 “Requirements Management in TFS”

2012.05.14: Latvijas Universitāte:

18:15 – 19:15 “Funkcionālā programmēšana - F#“

2012.05.17: Ventspils Augstskola:

11:00 – 11:45 “Designing Software Architecture in VS 2010”

12:45 – 13:30 “C# 3.0 & C# 4.0”

13:40 – 14:25 “MSF & Agile”

14:35 – 15:20 “Requirements Management in TFS”

2012.05.21: Latvijas Universitāte:

18:15 – 19:15 “C# 5.0 – async”

2012.05.28: Latvijas Universitāte:

18:15 – 19:15 “Ievads jQuery“

Cerams, ka noderēs!

Pēdējais treniņa inventārs

valdis.iljuconoks — Tue, 04 May 2010 09:58:05 GMT

Līdz ar Visual Studio pēdējās versijas oficiālo iznākšanu š.g. aprīļa vidū ir pieejams arī treniņa inventārs, kas paredzēts lai efektīvāk apgūtu jaunās tehnoloģijas un iespējas, kas jaunajā studijā nav maz.

Visual Studio 2010 Training Kit ietver sevī šādas tehnoloģijas:

C# 4
Visual Basic 10
F#
Parallel Extensions
Windows Communication Foundation
Windows Workflow
Windows Presentation Foundation
ASP.NET 4
Windows 7
Entity Framework
ADO.NET Data Services
Managed Extensibility Framework
Visual Studio Team System

Pakotnes izstrādē galvenokārt ir piedalījušies eksperti no Microsoft Developer & Platform Evangelism grupas.

Pieejams – šeit.

Cerams, ka noderēs!

jQuery prezentācijas materiāli

valdis.iljuconoks — Sun, 29 Nov 2009 16:23:00 GMT

Sveicins visiem!

Ir pieejami ir pagājušās .Net lietotāju grupas sanāksmes, kas norisinājās 2009-11-26 Kongresu namā, prezentācijas materiāli par “jQuery” šeit.

Cerams, ka noderēs!

Uzsildiet aplikācijas baseinu

valdis.iljuconoks — Tue, 18 Aug 2009 07:41:46 GMT

Cik reizes ir nācies dzirdēt ko klientiem vai kolēģiem, ka tīmekļa sistēmas pirmais pieprasījums ir nenormāli lēns un vispār – tur kaut kas nestrādā.

Tā ir ierasta prakse, ka daudzas lietas, kas ir nepieciešamas sistēmas darbībai tiek kešotas un kešošanas operācijas tiek veiktas Global.asax tipā Application_Start metodē. Šī metode tiek izsaukta pie aplikācijas domeina inicializācijas, kas parasti notiek kopā ar pašu pirmo sistēmas pieprasījumu. Lai kāds no sistēmas klientiem nekristu par upuri pirmajam pieprasījumam, kas var ieilgt pat līdz pāris minūtēm (ir redzētas tādas aplikācijas :)), tad parasti izstrādātāji nodarbojas ar abstrakto mākslu un mēģina izdomāt dažādus paņēmienus, kādā veidā varētu sistēmas aplikācijas baseinu (angl. application pool) mākslīgi uzsildīt, nosūtot pirmo pieprasījumu uzreiz pēc sistēmas palaišanas vai pārlādes.

Šajā risinājumā problēma vēl joprojām pastām – aplikācijas baseina pārlāde var notikt arī bez cilvēka iejaukšanās (dažādi recycling politikas nosacījumi). Ja aplikācijas pool uzsildīšanas mehānisms nav pietiekoši spēcīgi attīstīts, kāds klients tik un tā kritīs par upuri pirmajam ilgajam pieprasījumam.

Šoreiz stāsts par interesantu iespēju, kas nākusi klajā kopā ar IIS 7.5 versiju (Windows 7 vai Windows 2008 R2). Šī jaunā iespēja saucās “autoStart” un dod iespēju atzīmēt aplikācijas pool par ilgdzīvotāju jeb marķēt to kā nemirstīgo ar atzīmi startMode=”AlwaysRunning” zem attiecīgā system.applicationHost/applicationPools elementa applicationHost.config failā. Fails starp citu atrodas %windir%\system32\inetsrv\config direktorijā. Daudz lietas nu jau ir iespējams konfigurēt izmantojot lietotāja interfeisu no IIS pārvaldīšanas moduļa, tomēr šīm izmaiņām būs nepieciešams modificēt .config failu ar rokām, tāpēc ieteicams izveidot rezerves kopiju pirms manipulācijas.

Tātad konfigurācija izskatās šāda konkrētajam aplikāciju pool’am:

<configuration>
    <system.applicationHost>
        <applicationPools>
            <add name="Default .NET 4 App Pool" autoStart="true"
                 startMode="AlwaysRunning" managedRuntimeVersion="v4.0" />
        </applicationPools>
    <!—Additional content -->

Vadoties pēc IIS konfigurācijas faila shēmas, atribūtam “startMode” ir pieejamas divas vērtības”: “OnDemand”, kas nosaka, ka aplikāciju pools tiks startēts pēc nepieciešamības, un “AlwaysRunning”, ko izmantosim šajā piemērām. Šis uzstādījums regulē Windows Activation Service (WAS) darbību, kas nodrošina attiecīgā aplikācijas baseina palaišanu uzreiz pēc sistēmas (IIS) startēšanas vai pārstartēšanas. Nākamā iespēja ir šajā ielādes laikā, kad WAS neatkarīgi no tīmekļa pieprasījumiem veic aplikācijas baseina uzstartēšanu, veikt kādas nepieciešamās operācijas – piemēram, kešatmiņas ielādi no datubāzes, kas parasti ir laika ziņā apjomīgs darbs. Šī iespēja tiek piedāvāta ar piegādātāju (angl. providers) arhitektūru, kas dod iespēju veikt šādas nepieciešamās operācijas. Par cik vienā aplikācijas baseinā var plunčāties vairākas sistēmas, tad autoStartProvider kolekcija tiek definēta aplikāciju līmenī katrā no tīmekļa vietnēm.

<configuration>
    <system.applicationHost>
        <sites>
            <site name="Default Web Site" id="1">
                <application path="/WebApplication2"
                             applicationPool="Default .NET 4 App Pool"
                             serviceAutoStartEnabled="true"
                             serviceAutoStartProvider="PrewarmMyCache">
                    <virtualDirectory path="/"
                                      physicalPath="C:\inetpub\wwwroot\WebApplication2" />
                </application>
                <bindings>
                    <binding protocol="http" bindingInformation="*:80:" />
                </bindings>
            </site>
            <!-- Additional site definitions -->
        </sites>

Tātad tiek definēta vai vispār ir nepieciešama šāda iespēja (serviceAutoStartEnabled), kā arī tiek definēts, kurš piegādātājs ir jāizsauc.

Uzstartēšanās piegādātāji tiek definēti serviceAutoStartProviders elementā. Zemāk esam nodefinējuši tikai vienu piegādātāju:

<configuration>
    <system.applicationHost>
        <serviceAutoStartProviders>
            <add name="PrewarmMyCache" type="WebApplication2.CacheWarmupProvider, WebApplication2" />
        </serviceAutoStartProviders>

Šim definētajam tipam (WebApplication2.CacheWarmupProvider) ir jāimplementē “System.Web.Hosting.IProcessHostPreloadClient” interfeiss. Definēto tipu un asembliju WAS mēģina ielādēt no tās pašas tīmekļa aplikācijas bin/ direktorijas.

using System.Threading;
 
namespace WebApplication2
{
    public class CacheWarmupProvider : System.Web.Hosting.IProcessHostPreloadClient
    {
 
        public void Preload(string[] parameters)
        {
            // for instance, load classifiers from DB
            // and perform any other expensive operations
        }
    }
}

Pēc piegādātāja metodes sekmīga izsaukuma, tīmekļa sistēma tiek atgriezta ierastā kārtībā un gatava sākt apkalpot pieprasījumus.

NB! Tomēr pagaidām, kamēr nav iznācis oficiāli ASP.NET 4 versija, pastāv nelielas domstarpības par šo iespēju. ASP.NET oficiālā dokumentācija raksta, ka applicationHost.config failā ir nepieciešams uzrādīt citus tīmekļa mājvietas elementu atribūtus (attiecīgi “preloadEnabled” un “preloadProvider”). Un attiecīgi laikā, kad notiek preload piegādātāja metodes izsaukums, ASP.NET sistēmai bija jāieslēdzas speciālā režīmā, kurā uz laiku neapstrādā nevienu HTTP pieprasījumu, un lietotājam par to paziņo. ASP.NET oficiālajā dokumentācijā stāv gan rakstīts, ka šāda iespēja ir izmantojot IIS 7.5 uz Windows 2008 R2. Kamēr OS vēl nav apskatīts, neko vairāk nevaru pateikt ;)

Šāda lūk ir jaunā IIS 7.5 iespēja.

Cerams, ka noderēs!

Konfigurācijas transformācijas

valdis.iljuconoks — Thu, 02 Apr 2009 04:53:37 GMT

Cik bieži ir nācies nogādāt pie klienta tīmekļa veida aplikāciju, kurai ir palicis vecais DEBUG režīma konfigurācijas fails, ar izslēgtiem customErrors vai <compilation/> debug=true slēdžiem? Ir gadījies.. :)

Tā lūk, jaunā studija piedāvā nebijušu iespēju – konfigurācijas failu transformāciju pakošanas laikā.

Pēc noklusējuma, kad pievienojam jaunu Web Application projektu, tiek izveidoti sekojoši transformācijas faili:

Debug un Release konfigurācijas failu transformācijas faili ir pievienoti automātiski, par cik jauns projekts tiek veidots ar šīm konfigurācijām. Ja pievienojam jaunu (izmantojot Configuration Manager), tad nospiežot labo taustiņu uz web.config faila ir pieejama komanda, kas pievienos trūkstošo konfigurāciju transformācijas failus:

Kā rezultātā iegūstam jaunu Web.Staging.config failu, kas pagaidām ir gandrīz tukšs:

Transformācijas faili ir tikai dizainēšanas laika faili un netiek nogādāti pie klienta vai uz ražošanas vidi. Ja nu tomēr gadās šos failus arī aizgādāt līdz ražošanas videi, tad šie faili nenodara nekādu ļaunu, jo izpildes režīmā šie faili netiek izmantoti un ASP.NET neļauj klientiem iegūt .config failu saturu.

Šajos transformācijas failos tiek rakstīta Xslt transformācijas, kuras ir nepieciešams veikt ar orģinālo web.config failu.

Xml vārdu telpa “XML-Document-Transform” satur divus jaunus atribūtus:

Transform – šis atribūts informē transformācijas dzinēju, kas tieši ir jāmaina web.config failā.
Locator – šis atribūts informē transformācijas dzinēju, kur tieši ir jāmaina web.config failā.

At the time of writing, Transform ir šādas iespējas:

Replace – iespējams aizvietot kādu konfigurācijas ierakstu (replace node);
Insert – iespējams ievietot kādu konfigurācijas ierakstu (insert node);
Delete – iespējams izdzēst kādu konfigurācijas ierakstu (delete node);
Remove Attribute – iespējams nodzēst kāda konfigurācijas ieraksta atribūtu (remove attribute);
Set Attribute - iespējams piešķirt vērtību kāda konfigurācijas ieraksta atribūtam (set attribute);

At the time of writing, Locator ir šādas iespējas:

Match – sameklēt kādu konfigurācijas ierakstu pēc atribūta vērtības;
Condition – nosacījumu konfigurācijas ieraksta meklēšana;
XPath – precīza konfigurācijas ieraksta sameklēšana pēc XPath izteiksmes;

Ar šīm zināšanām mēģināsim transformēt noklusēto web.config failu, kurā ir appSettings testa konfigurācijas ieraksts:

Pieņemsim, ka “Staging” izpildes konfigurācijā, nav nepieciešams rādīt verbose ziņojumus, kas nozīmē, ka ir jāveido transformācijas fails, kas šo vērtību no true pārliks uz false.

Vienkāršākais Web.Staging.config faila saturs ir attēlots zemāk:

Transformācijas dzinējs pēc sameklēts attiecīgos configuration/appSettings konfigurācijas ierakstus un pielietos transformāciju tikai showVerboseMessages ierakstam, par cik xdt:Locator norāda uz to, ka jāmeklē ir pēc key atribūta attiecīgais konfigurācijas ieraksts un jāveic ir pilnā ieraksta (node) aizvietošana par ko informē xdt:Transform atribūts.

Kā redzams, tad transformācijas fails nesatur nevienu citu konfigurācijas ierakstu, jo transformācijas dzinējs veic orģinālā faila un transformācijas faila apvienošanu (merge) transformācijas procesa laikā.

Kad ir izveidots transformācijas fails, ir iespējams veikt transformācijas vai nu no komandrindiņas vai arī no Visual Studio.

No komandrindiņas tas ir gaužām vienkārši (Start -> Program Files –> Visual Studio v10.0 –> Visual Studio tools –> Visual Studio 10.0 Command Prompt):

MSBuild “Path to Application project file (.csproj/.vbproj) ” /t:TransformWebConfig /p:Configuration=Staging

Kad būvējums ir pabeigts, jaunās konfigurācijas faili glabāsies obj/Staging direktorijā.

Aplūkojot failu redzams, ka transformācija ir izpildīta pareizi.

Ja web.config konfigurācijas faili ir izvietoti arī kādā no apakšdirektorijām, tad VS transformācijas dzinējs atbalsta arī šāda veida scenārijus un viss iepriekš minētais attiecas arī uz citiem web.config failiem projektā.

Nākamajos rakstos mēģināšu pastāstīt, ko tad īsti iesākt ar šo obj/<Configuration> direktoriju saturu un kā notiek Web Application nodošana klientam vai instalācija uz ražošanas vides izmantojot jaunās VS2010 iespējas.

Cerams, ka noderēs!

Kā sadzīvot ar ShP 3.0 ?

valdis.iljuconoks — Fri, 13 Mar 2009 20:28:06 GMT

Šis ir viens no sērijas "for self reference" rakstiem, par lietām, kas kādreiz varbūt būs noderīgas arī kādam citam :)

Vai ir nācies sadzīvināt kopā Asp.Net aplikāciju tajā paša komunālajā dzīvoklī, kurā jau mitinās Windows SharePoint Services? Nesen man nācās šādā komunālajā dzīvoklī apvienot 2 ģimenes, kuru pārstāvēja jau pastāvīgais iemītnieks - Windows SharePoint services un Asp.Net 2.0 sistēma, vulgaris.

Tātad ir jāpielieto sekojošas darbības, lai šāda kopdzīve izveidotos sekmīga:

Ja vecākajās Sharepoint versijās pastāvēja smuks "Exclude managed path" saraksts, tad jaunajā versijā ir tikai "Include managed path" :)
Jaunajā Sharepoint versijā pietiek ar to, ka Asp.Net sistēmas izejas failus iekopē tajā pašā IIS virtuālajā mājvietā (web site) un nokonfigurē to kā IIS aplikāciju, kas automātiski paziņo Sharepoint Url dispetčerim, ka šis ceļš nav Sharepoint pārvaldīts.
Tālāk ir jākonfigurē Asp.Net sistēmas web.config fails:
Jāiestāda atpakaļ nepieciešamais drošības līmenis (Trust Level), par cik Sharepoint pārvaldībā ir IIS galvenā tīmekļa mājvieta, kas nozīmē, ka visas pakļautās mājvietas pārņem uzstādījumus no galvenās, ja vien nav minēts savādāk pašos applikācijas uzstādījumos. Sharepoint pēc noklusējuma griežas zem minimālās drošības pakāpes (Minimum). Vairums sistēmu ir nepieciešams vai nu vismaz Medium vai Full drošības līmenis. To far izdarīt pievienojot configuration/system.web elementam jaunu elementu:

Jāpievieno atpakaļ Http handleri, kas apstrādās aspx paplašinājuma lapas. To var izdarīt pievienojot jaunu elementu configuration/system.web/httpHandlers, kas atbildēs par aspx lapu apstrādi:

Ja gadījumā tiek izmantota Asp.Net sesija, kas 99% sistēmu parasti tiek darīts, tad noteikti ir jāatjauno sesijas iespēja Asp lapās, kas izdarāms, pievienojot jaunu atribūtu configuration/system.web/pages elementam enableSessionState="true".

Ja pēc šīm darbībām Asp.Net sistēma vēl joprojām atsakās strādāt, kā tas arī bija manā gadījumā ar 3 host sistēmām, kas bija jāiedzīvina Sharepoint dzīvoklī, tad nepieciešams pievienot arī trūkstošos Http moduļus configuration/system.web/httpModules elementam:

Pēc šīm veiktajām darbībām sistēmai vajadzētu sākt darboties, bet tas protams negarantē 100% vienlīdzību ar situāciju, kurā Asp.Net sistēma darbojas neatkarīgājā vidē, jo iespējams, ka kāds uzstādījumus, kuru izmanto sistēma Winows SharePoint serveris ir pārrakstījis un tā vērtība neatbilst gaidītajai.

Tā kā - jābūt uzmanīgiem :)

Cerams, ka noderēs!

Microsoft Asp.Net MVC RC2

valdis.iljuconoks — Wed, 04 Mar 2009 00:08:00 GMT

Laists klajā ir Asp.Net MVC dzinēja izlaidiena otrais kandidāts (iegādāties var šeit).

Pēc autoru vārdiem izmaiņas ir notikušas tooling un instalātora sadaļā - tāpēc vēlamies visiem, kas ir ieinteresēti vai arī nav ieinteresēti izmēģināt instalātoru uz visneiedomajākajām platformām un ziņot, ja nu gadījumā kaut kas ir nepareizi vai greizi.

Galvenā izmaiņa ir, ka instalators pieprasīs .Net 3.5 SP1 klātesamību, bet tas ir tikai instalācijas laikā. Izpildes režīmā, SP1 teorētiski nav arī nepieciešams.

Prieks redzēt, ka MVC dzinējs tuvojas RTM statusam beidzot. Pie tā esot strādājuši ~ 6 cilvēki.

Migrācija un dizaineri

valdis.iljuconoks — Tue, 13 Jan 2009 08:15:00 GMT

Šoreiz stāsts no sērijas "back-to-basics". Pierakstīju paša self-reference materiāliem...

Nesen gadījās portēt vienu aplikāciju, kas tika veidota .Net 1.1 platformā izmantojot Web Site tehnoloģiju tīmekļa aplikācijas izstrādei. Lapas kontroles un visi citi zvēri tika deklarēti turpat primārajā lapas izejas kodā (<lapas nosaukums>.aspx.cs) apmēram šādi:

/// <summary>

/// This is a text box.

/// </summary>

protected TextBox textBoxNumber;

Protams, ka šāds pieraksts nevienam netraucē, bet anyway gribējās, lai viss dizainera stuffs tiktu pārvietots uz .aspx.designer.cs failu. Nedaudz pameklējoties pa context-menu atradu "Convert to Web Application" komandu.

Tātad, lai korekti izveidotu .designer.cs failu, nepieciešams:

izdzēst visus nepieciešamos protected klases mainīgos, kas definē kādu elementu lapā;
izvēlēties "Convert to Web Application" komandu faila konteksta izvēlnē;
šī komanda izveidos korekti .designer.cs failu ar visiem nepieciešamajiem elementiem, kas tiks atrasti aspx lapā;
šī komanda padarīs arī nepieciešamo lapas klasi par partial, lai varētu definēt klases saturu vairākos failos;

Ja šādā veidā .designer.cs failu neizdodas izveidot, tad var mēģināt arī šādi:

atvērt aspx lapu source skatījumā;
iezīmēt visu Html kodu (Ctrl+A);
ievadīt kombināciju Ctrl+K un pēc tam Ctrl+F, kas saformēs pa jaunu Html izejas kodu un vajadzētu tam arī izveidot pa jaunu .designer.cs failu;

Prieks redzēt, ka vecās sistēmas arī dzīvo un tās konvertējot uz modernākām tehnoloģijām sajūta, ka dod tām otro iespēju! :)

Cermas, ka noderēs!

ListView, ObjectDataSource un Linq

valdis.iljuconoks — Fri, 30 May 2008 20:23:00 GMT

Šodien, papildinot Tfs laika uzskaites moduli, par kura 3. daļu man ir jāatvainojas, ka nav sanācis laika turpināt sēriju, uzskrēju virsū interesantai lietai, par kuru vēlējos pastāstīt.

Tātad laika uzskaites pārskata lapa, kas attēlo pavadīto laiku pie konkrētā darba jeb Work Item, ieguva sev Ajax šarmu un pēc rediģēšanas operācijas sarakstā, tas vairs nepārlādējas nozibsnījot visai lapai, bet gan eleganti pārlādējas, jo ievietots UpdatePanel kontrolē. Pārskatot kodu un pamazām to pucējot uz publicēšanu, nolēmu ar rokām rakstīto asp:Repeater kontroli aizvietot ar asp:ListView.

ListView kontrole pa lielam ir DataGrid un Repeater apvienojums, piedāvājot šablona elastīgumu no Repater kontroles un rediģēšanas iespējas no DataGrid. Ši kontrole ir ērtāka par DataGrid, jo piedāvā lielāku kontroli pār to, kā izskatīsies datu rediģēšanas kontrole klientam, tajā pašā laikā saglabājot visas spēcīgās DataGrid iespējas.

Tātad šoreiz ir stāsts par sekojošiem aktieriem galvenajās lomās: lietotāja saskarnei tiek izmantots ListView kontrole datu attēlošanai sarakstā (Grid style), ObjectDataSource kā datu avots, kurš tiek pievienots pie paštaisīta datu pārvaldnieka jeb vārtejas uz datu avotiem. Zem pārsega slēpjas Linq to Sql tehnloģija, lai iegūtu datus no datu bāzes, kā arī veikti saglabāšanas, rediģēšanas un dzēšanas operācijas.

ObjectDataSource tiek pievienots paštaisītam datu pārvaldniekam viena iemesla dēļ - ja atceraties Tfs laika uzskaites moduļa arhitektūras bildi (sk. šeit), tad datu operācijas tiek veiktas citā servisā, kas nozīmē, ka lietotāja saskarsnē nebūs pieejams DataContext u tāpēc LinqDataSource nav iespējams izmantot. Šim nolūkam ir jāizmanto klasi no DataLayer bibliotēkas, kas nodrošina vārteju uz laika uzskaites datu rediģēšanas servisu.

Demonstrācijas nolūkiem izveidosim sekojošu datu pārvaldnieku:

public List<Customer> GetList()
{
    using (NorthwindDataContext ctx = new NorthwindDataContext())
    {
        return (from c in ctx.Customers
               select c).ToList();
    }
}

public void Delete(Customer customer)
{
    using (NorthwindDataContext ctx = new NorthwindDataContext())
    {

        ctx.Customers.Attach(customer);
        ctx.Customers.DeleteOnSubmit(customer);
        ctx.SubmitChanges();
    }
}

Šis datu pārvaldnieks nodrošina atlases un dzēšanas operācijas. Demonstrācijas nolūkiem vairāk arī nav nepieciešams.

Pēc tam mūsu lietotāju saskarnes slānī nodefinējam ObjectDataSource:

<asp:ObjectDataSource ID="ObjectDataSource1" runat="server"
    SelectMethod="GetList"
    TypeName="ObjectDataStoreTest.DataManager"
    DataObjectTypeName="ObjectDataStoreTest.Customer"
    DeleteMethod="Delete">
</asp:ObjectDataSource>

Tad nodefinējam ListView kontroli. Tā ka ListView kontrole izmanto šablonus, tad operāciju saites (Insert, Update, Delete) mums ir jāveido pašiem tajā vietā un pozīcijā, kurā mēs to vēlamies. Šim nolūkam atliek tikai kontrolei, kas nodrošinās kādu no datu manipulācijas operācijām norādīt CommandName atribūtu.

<asp:Button ID="DeleteButton" runat="server" CommandName="Delete" Text="Delete" />

Palaižot mūsu super-puper aplikāciju iegūstam smuki ģenerētu lietotāja interfeisu:

Šajā demonstrācijā mums interesē kāda no operācijām, šajā piemērā - Delete.

Ja mēs ievietojam Breakpoint Delete() operācijā mūsu datu pārvaldniekā, tad momentā, kad nospiežam Delete pogu, izsaukuma parametrā redzam sekojošu ainu:

Pēc ienākošā Delete operācijas parametra ir skaidrs, ka ListView kontrole visticamāk ģenerē operācijas parametru jeb Customer klases instanci.

Papētot sīkāk ListView kontroli, ieraugām DataKeyNames īpašību, kas nosaka, kuras objekta īpašības kalpo identifikācijai. Loģiski, ka Customer klasei mēs definējam CustomerID, kā DataKeyNames atribūtu:

<asp:ListView ID="ListView1" runat="server"
    DataSourceID="ObjectDataSource1"
    OnItemDeleting="ListView1_ItemDeleting"
    DataKeyNames="CustomerID">

Jaunajā redakcijā situācija izskatās savādāk:

Tātad šaudas ir apstiprinājušās, ListView pats ģenerē operācijas parametra klases instanci, norādot tai DataKeyNames atribūtus pārkopējot tos no instances, kuras kontekstā operācija ir izpildīta.

Šāds piegājiens, mūs īsti neapmierina, jo pielietojot standarta Linq to Sql iespējas:

using (NorthwindDataContext ctx = new NorthwindDataContext())
{

    ctx.Customers.Attach(customer);
    ctx.Customers.DeleteOnSubmit(customer);
    ctx.SubmitChanges();
}

Delete operācijai ir nepieciešams tieši tā pati klases instance, kas tika ielādēta, pretējā gadījumā iegūstam:

Kāds var man lūdzu paskaidrot, kas iepriekš jau ir saskāries ar šāda veida problēmām - es daru kaut ko nepareizi, vai tas ir by-design?

Ir viens variants, kas man ienāca prātā, kā varētu risināt šo nelielo pārpratumu - ieviešot dzēšanas operāciju (vai jebkuru cita veida operāciju) pēc identifikātoriem:

public void DeleteById(Customer customer)
{
    using (NorthwindDataContext ctx = new NorthwindDataContext())
    {
        ctx.Customers.DeleteOnSubmit (
            ctx.Customers.Single (c => c.CustomerID.Equals (customer.CustomerID)));
        ctx.SubmitChanges();
    }
}

Pēc pēdējām modifikācijām izriet, ka objekts, kas tiek nodots no ListView līdz attiecīgās operācijas metodei ir uzskatāms tikai kā DTO (data transfer objekts), kuram nekādas biznesa vērtības nav.

Kopsummā jaunā ListView kontrole ir diezgan pievilcīga, piedāvājot funkcionalitāti, kas līdz šim nebija pieejams - šabloni no Repeater kontroles, rediģēšanas iespējas no DataGrid. Protams, ir nepieciešams daudz maarkup elementus ielikt kodā, lai tas viss strādātu, bet pārlūkošanas un rediģēšanas iespējas tur pat uz vietas - patiešām ir jauka iespēja.

Jauks pievienojums ASP.NET 3.5 kontroļu saimei.

Cerams, ka noderēs!

Atjauninātais treniņa inventārs

valdis.iljuconoks — Fri, 23 May 2008 06:34:43 GMT

Microsoft izstrādātāju evanģēlistu grupa ir laidusi klajā nelielu pievienojumu advancētajam treniņa inventāram . Šis pievienojums ir domāts, lai apskatītu un darbotos ar Visual Studio SP1 un .Net Framework 3.5 SP1 . Šīs tehnoiloģijas tiek aplūkotas treniņa...(read more)

Advancēts treniņa inventārs

valdis.iljuconoks — Sun, 13 Apr 2008 18:54:58 GMT

Evanģēlistu grupa Microsoft koorporācijā ir izlaidusi jaunu treniņa inventāru, kas ir advancēts līdz pēdējām .Net 3.5 Framework pievienojumiem.

Treniņu laikā Jums būs iespēja apskatīt tādas lieliskas tehnoloģijas, kā:

ASP.NET MVC Framework
ASP.NET Dynamic Data
ASP.NET Ajax History
ASP.NET Silverlight Controls
ADO.NET Data Services
ADO.NET Entity Framework

Inventārs atrodas šeit. Treniņa piederumi pārējam .Net Framework 3.5 sadaļām ir iegūstama šeit.

Atslogo tīmekļu servisus ar kešu

valdis.iljuconoks — Sat, 05 Apr 2008 20:45:00 GMT

Yo!

Sen nekas nav rakstīts... Daudz laika ir aizgājis HHH pasākuma sagatavošanās darbiem, kā arī Community Launch notikumam.

Ta kā TFS timesheet 3. daļa vēl ir rakstīšanas stadijā (1. un 2. apskatāma zem linkiem), šoreiz gribēju pieminēt vienu interesantu lietu, par ko biju piemirsis un varbūt, ka arī Jums šis liksies sen aizmirsts triks :)

Tātad problēmas pamatbūtība bija: ir serviss, kas atgriež baitu plūsmu, kas patiesībā ir Pdf formāta izdruka. Risināmā problēma izvirzīja prasību, ka servisa izsaukumu skaits ir jāsamazina, ja serviss ir izpildījies sekmīgi. Samazināt izsaukumu skaitu nozīmē neizsaukt servisu atkārtoti, ja operāciju ir bijusi sekmīga. Kopīgās diskusijās ar kolēģiem (viens no viņiem bija Andrejs) nonācām pie secinājuma, ka problēmas būtība bija uzstādīta nepareiza. Pēc pāris domu gājieniem un potenciālo nākamo problēmu apspriešanas pie klienta puses keša, mēs izsecinājām, ka pareizā problēmas nostādne ir: atvieglot servisa darbību ar keša palīdzību, neizpildot sūri grūto darbu (izdrukas ģenerācija no kristāla šablona uz Pdf plūsmu), bet gan sekmīgo atbildi kešot servera galā.

Šim nolūkam mums ērti noder WebMethod atribūta papildus iespējas.

Tātad, ja mēs vēlamies sekmīgo servisa izsaukumu iekešot, mums būs nepieciešams iestatīt CacheDuration īpašības vērtību.

Tātad scenārijs ir sekojošs: pieņemsim, ka mums ir serviss, kas saņem 2 parametris, kaut ko ar tiem izdara un atgriež atbildi.

Zemāk ir parādīts tīmekļa servisa kods:

[WebMethod (EnableSession = false, CacheDuration = 5)]
public string SessionLessOperation(int param1, string param2)
{
    WriteLog ("Doing work in state less manner...");

    return string.Format ("You provided in session state '{0}' and '{1}' parameters."
        , param1, param2);
}

Tīmekļa servisam atbildi ir "jāpatur prātā" 5 sekundes. Lai to mēs vizuāli varētu novērtēt, izveidojam testa klientu mūsu izveidotajam servisam.

Tātad palaižam testa klientu un padarbināt nedaudz to.

No testa klienta redzams, ka patiesībā, visas darbības, kas tika izpildītas pēc 41 sekundes līdz 55 - patiesībā neizsauca nemaz tīmekļa servisa darbību, kas nozīmē, ka pieprasījums nemaz neskāra servisu un kešings notiek zemākā līmenī (Asp.Net handlera līmenī).

Nākamais jautājums, kas mani ieinteresēja ir - sesijas. Kas notiek ar sesijām, ja tīmekļa servisam tādas ir deklarētas ar EnableSession = true īpašības palīdzību.

Otra tīmekļa metode izsaktās šāda:

[WebMethod(EnableSession = true, CacheDuration = 5)]
public string SessionStateOperation(int param1, string param2)
{
    WriteLog("Doing work in session state manner...");

    if (Session["test-key"] == null)
    {
        Session["test-key"] = Guid.NewGuid();
    }

    return string.Format ("{0}: {1}\t{2}", Session["test-key"], param1, param2);
}

Šī metode izvada kādu patvaļīgi ģenerētu sesijas mainīgo, lai mēs pārliecinātos, ka tā ir tā pati sesija.

Testa klienta izsaukumu šāviņš:

Kā redzams, tad arī tīmekļa serviss, kas ir ieslēgta sesijas uzglabāšana tīri labi tiek galā ar servera puses kešingu.

Lai vēl konkrētāk pārbaudītu no sesijas atkarīgo servisu kešosas mehānismu ieviesīsim vēlvienu "klientu":

Btw, lai sekmīgi strādātu sesijas instance uz servera, nepietiek tikai ar tīru ģenerēto proxy klientu, pēc proxy klienta klases inicializācijas ir jāizpilda šāds kods, lai sekmīgi klients varētu uzglabāt servera ģenerētos sesijas identifikatorus (cookies):

srv.CookieContainer = new CookieContainer();

Jautājums: kas notiek ar WCF servisiem un kāds tur ir atbalsts kešingam? Ātri pārmeklējot MSDN specifikācijas, neko prātīgu uz pirmo sitienu neatradu. Tas ko ātrumā varēja izdomāt ir:

Izmantojot HttpRuntime objekti nokļūt līdz Asp.Net kešinga objektam un izmantot to;
Izmantot kaut kādu trešās puses kešošanas risinājumu (Enterprise Library, piemēram);
Ieviest savu implementāciju kešošanas problēmas risinājumam, parasti tas reducējas līdz objekta Dictionary<string, object> izmantošanai;

Pirmais risinājums nav elegants ar to, ka, tas piešķir zināmu lomu IIS un HTTP terminiem tavā risinājumā. Trešais risinājums parasti beidzas ar 'quick and dirty solution' (ko es parasti gan dēvēju par 'fast non solution' :)), kas parasti neatbalsta keša atkarību mehānismus (dependency policy) vai arī keša izbeigšanās politikas (expiration policy).

However, sameklēju inetā nelielu piemēru, kas risina tieši šo problēmu ar interfeisa IOperationInvoker palīdzību.

Par šo problēmu iespējams, ka nepietika laika norealizēt pietiekoši smuki jeb arī iespēja netika izmantota pietiekoši aktīvi pirms tam, un .Net komanda nolēma risinājumu pataupīt nākamajām versijām.

Toties WCF ir daudzas citas labas īpašības :)

Darbi

valdis.iljuconoks — Wed, 20 Feb 2008 08:34:59 GMT

Pirms laika uzskaites 2-ās daļas rakstīšanas, kuru es minēji šeit, bija doma nedaudz paeksperimentēt ar 2008 serveri, kā rezultātā pašlaik esmu nokrāvies ar reinstalācijas darbiem.

Rakstiņu ar sīkāku izklāstu par pielietotajām tehnoloģijām arhitektūru un niansēm pašlaik plānoju aprakstīt tikai nākamnedēļ :(

Līdz tam secinu, ka UT3 ir pagaidām ļoti nestabila spēle attiecībā pret darbināšanu dažādās vidēs. Nu, lai pienācis arī spēļu industrijai nerakstūrīgas tendences: gaidam UT3 Sp1 :)

līdz tam varētu ieteikt noteikti palūrēt Asp.Net MVC jauno dzinēju, kuru ļoti uzsaktāmi demonstrē Skots Hanselmans.

Kā skaņot Global.asax.cs līmeņa notikumus

valdis.iljuconoks — Thu, 16 Aug 2007 04:57:00 GMT

Līdz ar Visual Studio 2005 Microsoft ir izstrādājis Asp.Net Development Server, kas dod iespēju skaņot Asp.Net sistēmas bez IIS klātbūtnes uz izstrādātāja mašīnas.
Tomēr ir situācijas, kad sistēma ir palaižama tikai IIS vidē. Šādos gadījumos ir nedaudz problemātiski skaņot un atkļūdot Global.asax līmeņa notikumus, kā piemēram Application_Start() notikumu. Tādiem notikumiem kā Session_Start() ir iespējams ”pievienoties” arī pēc Application Domain ielādes.Notikums Asp.Net sistēmā tik izsaukts pie pirmā pieprasījuma sistēmai, kurai Application Domain vēl nav ielādēts. Kā rīkoties šādos gadījumos? Var mēģināt no Visual Studio laist projektu Debug režīmā (F5), bet citreiz arī šajos gadījumos esam saskārušies ar problēmu, ka Visual Studio izstrādes videi ir problēmas pievienoties IIS procesam sistēmas skaņošanai un atkļūdošanai.
Tātad problēma ir, ka Application_Start() notikuma skaņošanai ir nepieciešams jau Asp.Net process (aspnet_wp.exe vai w3wp.exe). Pēc IIS servisa restartēšanas šis process nav uzstartēts.Alternatīvais ceļš kā „pieslēgties” Asp.Net procesam pirms Application Domain ielādes jeb pirmā pieprasījuma sistēmai ir izsaukt Asp.Net ISAPI filtra darbību neizsaucot sistēmas ielādi.
Tagad pa soļiem. Ja Asp.Net sistēma ir izpildes režīmā IIS process eksistē uz servera:

Pēc „iisreset” komandas izpildes process tiek slēgts. Tas ir labi redzams no Visual Studio Debug->Attach to Process... dialoga loga:

Lai pieslēgtos IIS procesam pirms Asp.Net sistēmas uzstartēšanās, ir nepieciešams izsaukt Asp.Net ISAPI filtra darbību, ko var izdarīt pieprasot neeksistējošu .aspx lapu, jo IIS meta bāzē ir nokonfigurēts, ka failus ar paplašinājumu „.aspx” apstrādā Asp.Net ISAPI filtrs, kas nozīmē, ka neatkarīgi no tā vai fails eksistē vai nē, Asp.Net ISAPI filtrs tiks iedarbināts līdz ar IIS procesu.

No Visual Studio Debug->Attach to Process... dialoga loga ir redzams, ka pēc falšā pieprasījuma ir uzsācis darbību Asp.Net ISAPI filtrs un līdz ar to arī IIS process.

Pievienojoties (Attach) šim procesam un pēc tam pieprasot reālās sistēmas pieprasījumu ir iespējams nokļūt skaņošanas režīmā Global.asax faila notikumos.

Pieļauju, ka eksistē arī citas alternatīvās metodes, kādā veidā iekļūt šajos notikumos, bet šī man šķiet visātrākā un vienkāršākā.

AspNet lokalizācijas problēma

valdis.iljuconoks — Wed, 15 Aug 2007 08:42:00 GMT

Doma pārtaisīt lokalizācijas jeb resursu ieguvi Asp.Net vides projektos man radās jau sen, bet tikai nesen nonācām līdz reālām darbībām resursu piegādātāja (angl. provider) izstrādē un pielāgošanā. Noklusēto jeb uz resx failiem bāzēto resursu piegādātāju aizvietošanas ieguvumus atstāsim citai reizei.

Asp.Net lokalizācijas objektu modelis ir veidots tā, ak to var ērti paplašināt un izstrādāt savu resursu ielādi, meklēšanas un uzglabāšanas mehānismu – implementējot noteiktus System.Resources un System.Web.Compilation interfeisus.

Objekta modeļa paplašināšanas nianses un knifiņi, lai pagaidām paliek citai reizei. Tas ko gribēju pastāstīt ir Asp.Net aplikācijas kompilācijas laika notikumi jūsu providerī.

Lokalizēt Asp.Net aplikāciju var dažādos veidos, ļoti būtiska nianse ir lokalizācija ar netiešo (angl. implicit) resursa norādi:

<asp:Localize

ID="labHello"

runat="server"

Text="[labHello]"

meta:resourcekey="labHelloResource1" />

Šī Asp.Net koda kompilācijas laikā kompilators izsaukts Asp.Net aplikācijā nokonfigurēto resursu piegādātāju, lai pārliecinātos, ka resursu glabātuvē eksistē šāds resursus (resursi tiek identificēti pēc meta:resourcekey atribūta vērtības).

private Localize __BuildControllabHelloLocal()

{

Localize __ctrl = new Localize();

base.labHelloLocal = __ctrl;

__ctrl.ID = "labHelloLocal";

__ctrl.Text = "[labHelloLocal]";

__ctrl.Text = Convert.ToString(base.GetLocalResourceObject("labHelloLocalResource1.Text"), CultureInfo.CurrentCulture);

return __ctrl;

}

Situācija ir sekojoša, ja kompilācijas laikā resursa piegādātājs nevar piegādāt resursu ar atbilstošo identifikatoru, tad Asp.Net kompilators kompilējamajā lapā nemaz nekompilē resursa piegādātāja izsaukumu:

private Localize __BuildControllabHelloLocal()

{

Localize __ctrl = new Localize();

base.labHelloLocal = __ctrl;

__ctrl.ID = "labHelloLocal";

__ctrl.Text = "[labHelloLocal]";

return __ctrl;

}

Par attiecīgā resursa pieejamību kompilācijas laikā biju domājis public System.Resources.IResourceReader ResourceReader {get;} izsaukumu resursa piegādātāja objektam. Šo kompilācijas laika problēmu varētu atrisināt ar workaroundu, ka resursu piegādātājs atgriež pieprasīto resursu „jebkuros apstākļos”, t.i., jebkuru resursu pēc tā identifikatora jebkurai kultūrai. Bet šis workarounds nestrādā, jo Asp.Net aplikācijas kompilators neizsauc resursu tieši (explicit) bet gan netieši (implicit). Netiešo resursu norādes koda kompilācijas laikā Asp.Net kompilators no resursu piegādātāja saņem IDictionaryEnumerator implementāciju, kas satur visus resursu identifikatorus. Vadoties pēc attiecīgā resursa esamības šajā resursu glabātuvē Asp.Net kompilators arī pieņem lēmumu par to, vai resursu piegādātāja izsaukums ir jākompilē kodā vai arī nav.

Lietas par ko jāatceras, ja implementē citu resursa piegādātāju:

- Kompilācijas laikā ir jābūt pieejamiem visiem resursiem. Tas nozīmē, ka ir jāpadomā par dienas (jeb pareizāk sakot nakts) būvējumu loģistiku, jo pirms kompilācijas resursu piegādātājam ir jāfunkcionē korekti (ja runa ir par datu bāzes bāzētu resursa piegādātāju).

- Par resursu neatrašanu kompilācijas laikā nekādu kļūdas paziņojumu nav, tas nozīmē, ka lokalizācijas trūkumu lapā var novērot tikai izpildes (angl. runtime) laikā. Šā iemesla dēļ labāk noklusēto tekstu lokalizējamajās vietās likt kontroles identifikatoru, lai situācijās varētu viegli atšķirt un sameklēt problemātiskos apgabalus.