Tutorials

Distributed Dataset in uno scenario Multi-Tier [2]

Davide Senatore — Wed, 14 Jan 2009 00:51:03 GMT

Riprendendo il discorso lasciato in un mio precedente post, vediamo di creare una soluzione che ci faccia capire come i Dataset Distribuiti possano essere utilizzati per creare soluzioni che impieghino questa tecnica per l'accesso ai dati.

Lavoreremo con un Database di nome ECommerce. La struttura è volutamente molto semplice (solo 2 tabelle) perchè non è importante complicare lo schema del database per comprendere come il Dataset Distribuito possa essere utilizzato per i nostri fini. Le tabelle sono Order e OrderDetail, collegate con una relazione uno a molti.

Procediamo creando un progetto di nome CodeSapiens.DataAccess, in cui creeremo il nostro dataset di nome DataContext.xsd, ed una classe DataManager che incapsulerà i metodi utilizzati per accedere ai dati. Dovremo creare contestualmente anche un progetto "Class Library" di nome CodeSapiens.Entities. Questo progetto verrà utilizzato indicando nel Dataset il "DataSet Project", ovvero il progetto in cui il dataset genererà le classi "entità". Come abbiamo già visto nel precedente post, infatti, il dataset distribuito separa nettamente l'accesso ai dati dalla parte di "entità".

Altra proprietà a cui fare attenzione nel Dataset è la "Hierarchical Update". La troveremo già impostata a True, e questo indica che il generatore di codice avrà generato per noi una classe TableAdapterManager ed un metodo UpdateAll che avrà come parametro un'istanza del nostro Dataset. Questo metodo consente di aggiornare tutte le tabelle del Dataset rispettando l'ordine delle relazioni tra le tabelle che compongono il dataset. In precedenza eravamo noi che dovevamo sopperire all'ordinamento degli insert/update/delete effettuati dal dataset. Per maggiori approfondimenti riguardanti questa interessante caratteristica vi invito a consultare questo riferimento.

Nel pezzo di codice seguente possiamo vedere i metodi della classe DataManager, la quale si occuperà di implementare i metodi ad alto livello che nasconderanno le particolari implementazioni a livello TableAdapter, stringa di connessione ed utilizzo del Dataset per quanto riguarda l'accesso ai dati. In pratica si tratterà di scrivere dei metodi che accettino in input tipi base del Framework e/o classi delle Entities derivate dal Dataset DataContext già creato nel nostro progetto.

/// <summary>
/// Salva un ordine
/// </summary>
/// <param name="order">Dataset che rappresenta l'ordine</param>        
public void SaveOrder(DataContext order)
{
    if (order != null)
    {
        CodeSapiens.DataAccess.DataContextTableAdapters.TableAdapterManager _ta = new CodeSapiens.DataAccess.DataContextTableAdapters.TableAdapterManager();
        _ta.OrderTableAdapter = new CodeSapiens.DataAccess.DataContextTableAdapters.OrderTableAdapter();
        _ta.OrderDetailTableAdapter = new CodeSapiens.DataAccess.DataContextTableAdapters.OrderDetailTableAdapter();
        _ta.Connection.ConnectionString = _connectionString;
        _ta.UpdateAll(order);
    }
    else
    {
        throw new Exception("Order can't be null.");
    }
}
  
/// <summary>
/// Carica un ordine
/// </summary>
/// <param name="orderId">Id interno (guid) dell'ordine</param>
/// <returns></returns>
public DataContext LoadOrder(Guid orderId) 
{
    DataContext _context = new DataContext();
    DataContextTableAdapters.OrderTableAdapter _orderAdapter = new DataContextTableAdapters.OrderTableAdapter();
    _orderAdapter.Connection.ConnectionString = _connectionString;
    DataContextTableAdapters.OrderDetailTableAdapter _orderDetailAdapter = new DataContextTableAdapters.OrderDetailTableAdapter();
    _orderDetailAdapter.Connection.ConnectionString = _connectionString;
    _orderAdapter.FillByOrderId(_context.Order, orderId);
    _orderDetailAdapter.FillByOrderId(_context.OrderDetail, orderId);
    return _context;
}

Notiamo come tutto il codice sia privo di istruzioni SQL. Queste istruzioni sono memorizzate all'interno dei Table Adapters a livello di Dataset, e sono istruzioni SQL che abbiamo scritto personalmente. Vediamo dei fatti derivanti da questo approccio:

Posso scrivere il codice SQL ESATTAMENTE come voglio, ottimizzando così le mie query
Devo scrivere il codice di tutte le query, mentre con altri approcci questo viene autogenerato (a run time o a design time)
Ho un unico punto in cui scrivere tutto il codice SQL
Posso usare delle Stored Procedures se voglio implementare un accesso ai dati tramite esse

In questo post utilizzeremo la classe DataManager in un progetto a due livelli, ovvero Client-Server. Creiamo quindi un progetto WinForm per consumare il nostro dataset. Al progetto aggiungeremo come riferimenti il progetto CodeSapiens.DataAccess e CodeSapiens.Entities e scriviamo una semplice interfaccia composta da due finestre, la principale con la lista degli ordini e la seconda da utilizzare per la modifica/creazione del singolo ordine.

Per la gestione dell'associazione dati-interfaccia impiegheremo il Databinding a design time di Visual Studio. A questo riguardo, dobbiamo fare una precisazione: tutto il databinding viene fatto tramite le entities del progetto Codesapiens.Entities, e non tramite il Dataset DataContext. Questo è molto importante, perchè in pratica crea un legame tra l'interfaccia e queste entità e non tramite l'interfaccia e l'accesso ai dati.

public partial class MainForm : Form
{
    public MainForm()
    {
        InitializeComponent();
    }
  
    private void Form1_Load(object sender, EventArgs e)
    {
        LoadOrders();
    }
  
    private void LoadOrders()
    {
        CodeSapiens.DataAccess.DataManager _dm = new CodeSapiens.DataAccess.DataManager();
        dataContext_OrderDataTableBindingSource.DataSource = _dm.LoadOrders().Order;        
    }
    
    private void bindingNavigatorAddNewItem_Click(object sender, EventArgs e)
    {
        EditOrderDialog _dialog = new EditOrderDialog();
        if (_dialog.CreateNewOrder() == DialogResult.OK)
        {
            LoadOrders();
        }
    }
  
    private void dgvOrders_DoubleClick(object sender, EventArgs e)
    {
        EditOrderDialog _dialog = new EditOrderDialog();
        if (_dialog.EditOrder(((DataContext.OrderRow)((DataRowView)dgvOrders.SelectedRows[0].DataBoundItem).Row).Id) == DialogResult.OK)
        {
            LoadOrders();
        }
    }
}

La form principale è estremamente semplice in quanto deve solamente caricare la lista degli ordini e permettere di andare in modifica o creazione di un nuovo ordine.

public DialogResult CreateNewOrder()
{
  dataContext.OrderDetail.TableNewRow += new DataTableNewRowEventHandler(OrderDetail_TableNewRow);
  DataContext.OrderRow _newOrder = dataContext.Order.NewOrderRow();            
  _newOrder.Id = Guid.NewGuid();
  _newOrder.OrderDate = DateTime.Today;
  _newOrder.ShipmentAddress = string.Empty;
  _newOrder.CustomerAddress = string.Empty;
  dataContext.Order.AddOrderRow(_newOrder);
  return ShowDialog();
}
  
public DialogResult EditOrder(Guid orderId)
{
  dataContext.OrderDetail.TableNewRow += new DataTableNewRowEventHandler(OrderDetail_TableNewRow);
  dataContext.Merge(_dm.LoadOrder(orderId));
  return ShowDialog();
}
  
void OrderDetail_TableNewRow(object sender, DataTableNewRowEventArgs e)
{
  ((DataContext.OrderDetailRow)e.Row).Id = Guid.NewGuid();
}
  
private void btnSaveAndClose_Click(object sender, EventArgs e)
{            
  orderBindingSource.EndEdit();
  orderDetailDataGridView.EndEdit();
  orderDetailBindingSource.EndEdit();
  _dm.SaveOrder((DataContext)dataContext.GetChanges());
  this.DialogResult = DialogResult.OK;
}

La form per la creazione/modifica ordine è anch'essa molto semplice, e l'accesso ai dati è mantenuto al minimo. In questo esempio non sono state gestite problematiche riguardanti concorrenza, possibili errori dovuti a errori sul database e tutto è stato semplificato per far emergere l'utilizzo del dataset distribuito.

A questo punto possiamo fare un riassunto e vedere che cosa abbiamo guadagnato con questo approccio, considerato che stiamo realizzando un Client-Server:

Se cambiamo qualcosa sul database, è sufficiente aggiornare il Dataset per vedere propagate le modifiche anche a livello di entità
Utilizzando il databinding di Visual Studio a Design-Time abbiamo a disposizione un eccezionale strumento che ci assicura un'ottima produttività
Possiamo accedere anche a database non-SQL Server (Oracle, Sybase, ODBC generici), contrariamente a LINQ2SQL
Non dobbiamo gestire a mano l'entity tracking, in quanto il dataset lo fa per noi
Utilizzando i guid abbiamo risolto il problema della gestione dei campi identity sul database. Inoltre vedremo che in ambiente distribuito questa si rivelerà una scelta felice
Non ci dobbiamo preoccupare dell'ordine dell'aggiornamento delle tabelle, in quanto il TableAdapterManager con le opportune configurazioni segue l'ordine di Update/Insert/Delete corretto
Le classi delle entities, come quelle per l'accesso ai dati (TableAdapters), possono essere estese mediante l'uso delle partial class, permettendo così di implementare funzioni con visibilità limitata al progetto in cui si trovano

Ovviamente, come già detto nell'articolo precedente, questo approccio è da tenere in considerazione per applicazioni RAD di dimensioni medio/piccole. Non deve mai essere sottovalutato il fatto che comunicando attraverso le entità del dataset stiamo legando il modello (database) alla rappresentazione (interfaccia). Anche se questo può essere ricorrente e accettabile in un numero molto elevato di applicazioni (tipicamente proprio in quelle medio piccole con requisiti di tempistiche molto strette), in applicazioni enterprise di grosso livello può non essere consigliabile. Nel prossimo post relativo a questo argomento vedremo come utilizzare un servizio WCF per esporre le entità e come modificare l'applicazione Client-Server per farle utilizzare i servizi, piuttosto che accedere direttamente al database. Il codice sorgente dell'applicazione è scaricabile a questo indirizzo.

Scrivere un control class converter per VB6(2)XAML

Davide Senatore — Wed, 29 Nov 2006 17:05:00 GMT

Per tutti coloro i quali sono interessati all'utilizzo ed alla personalizzazione del tools VB6(2)XAML, pubblico un esempio di come possa essere possibile ridefinire il rendering dell'elemento VB.Label con una classe proprietaria. Dopo aver creato un progetto di tipo ClassLibrary, possiamo aggiungere la referenza a VB62XAML.exe nella quale si trova la classe VBControl, dalla quale dovremo ereditare.

Implementando un override del metodo RenderToWPF possiamo definire come renderizzare il nostro controllo Label. Nell'esempio che ho riportato sotto, è possibile osservare una tecnica basata sulla creazione "manuale" degli elementi, ed un'altra basata sull'utilizzo di templates che magari possono essere caricati da disco.

Imports System.Xml
Imports CodeSapiens.VB62XAML

Public Class MyLabel
    Inherits CodeSapiens.VB62XAML.VBControl

    ''' <summary>
    ''' Override base function RenderToWPF and replace with new rendering attributes
    ''' </summary>
    ''' <param name="document">The XML document that parser passes to classes</param>
    ''' <returns>XMLElement representing the control in XML Format</returns>
    ''' <remarks></remarks>
    Public Overrides Function RenderToWPF(ByVal document As System.Xml.XmlDocument) As System.Xml.XmlElement
        'Create element
        Dim _item As XmlElement = document.CreateElement("Label")
        'Set base positioning attributes
        _item.SetAttribute("Name", Helpers.BuildName(Me.Name, Me.Properties))
        _item.SetAttribute("Canvas.Left", Helpers.TwipsToPixels(Convert.ToInt32(Me.Properties.GetProperty("Left").Value)))
        _item.SetAttribute("Canvas.Top", Helpers.TwipsToPixels(Convert.ToInt32(Me.Properties.GetProperty("Top").Value)))
        _item.SetAttribute("Width", Helpers.TwipsToPixels(Convert.ToInt32(Me.Properties.GetProperty("Width").Value)))
        _item.SetAttribute("Height", Helpers.TwipsToPixels(Convert.ToInt32(Me.Properties.GetProperty("Height").Value)))

        _item.SetAttribute("Content", Me.Properties.GetProperty("Caption").Value)
        _item.SetAttribute("Padding", "0,0,0,0")

        'Create a document fragment to show another manner of embedding XML in Control Rendering
        Dim _docFrag As XmlDocumentFragment = document.CreateDocumentFragment()

        Dim _gradientTemplate As String = String.Empty
        ' This string could be loaded from disk, and maybe values could be placeholders
        ' so we can substitute them at run-time using our special values...
        _gradientTemplate = "<Label.Background>" & _
                            "    <LinearGradientBrush StartPoint=""0.5,0"" EndPoint=""0.5,1"">" & _
                            "       <GradientStop Offset=""0.0"" Color=""LightBlue""/>" & _
                            "       <GradientStop Offset=""1.0"" Color=""SlateBlue""/>" & _
                            "   </LinearGradientBrush>" & _
                            "</Label.Background>"

        _docFrag.InnerXml = _gradientTemplate
        _item.AppendChild(_docFrag)

        'Handle font generation
        If Me.Properties.ContainsProperty("Font") Then
            Me.RenderFont(Me.Properties.GetProperty("Font"), _item)
        End If

        Return _item
    End Function

End Class

Uno dei punti fondamentali, comunque, è rappresentato dalla "dichiarazione" fatta nel file .config dell'applicazione, del class converter che utilizzerà il controllo Label:

<add key="VB.Label" value="CustomControls, CustomControls.MyLabel"/>

Articolo su WSE 3.0 e ASP.net Membership API

Davide Senatore — Tue, 10 Oct 2006 12:00:00 GMT

Con mio grande piacere, oggi è stato pubblicato il mio ultimo articolo sul sito di XeDotNet. Nell'articolo in questione si parla di autenticazione ed autorizzazione tramite WSE 3.0 e Membership API. Grazie all'approccio trattato si può realizzare un sistema Single Sign On tra Web Services ed applicazioni ASP.net, condividendo l'identità dell'utente tra le varie applicazioni. Lo potete trovare qui.

Single Sign-On con ASP.net 2.0 e Membership API

Davide Senatore — Wed, 07 Jun 2006 18:15:00 GMT

Spesso mi è capitato di imbattermi nel problema di avere più applicazioni web che permettano agli stessi utenti di autenticarsi e di lavorare liberamente al loro interno. Ancora più spesso mi sono imbattuto nella difficoltà di realizzare tale obiettivo, soprattutto per via del fatto che ogni applicazione web implementava l'autenticazione a modo suo, con risultati spesso discutibili dal punto di vista della sicurezza.

Molte volte ci siamo trovati a valutare come sistema di Single Sign-On l'autenticazione su Active Directory, ma questa è fattibile soprattutto in ambienti intranet e non in un ambiente internet, dove magari i nostri utenti possono addirittura auto-registrarsi.

L'eleganza della Membership API permette di sorpassare ogni problema, raggiungendo l'obiettivo di condividere le credenziali dell'utente attraverso più applicazioni web. Ovvero si potrà, ad esempio, creare un'applicazione web dedicata alle vendite e, successivamente, un'applicazione web dedicata alla reportistica. Queste due applicazioni potranno condividere le informazioni relative agli utenti ed ai loro ruoli, in modo da uniformare la gestione della sicurezza.

Ora, come implementare una feature così appetibile? Beh, vi assicuro che è più facile farlo che spiegarlo ...

Come prima cosa, dobbiamo evitare di usare il "classico" database SQL express che il buon vecchi VS2005 crea automaticamente per noi. Piuttosto, creiamo un database che fungerà da repository condiviso di credenziali (Shared Credential Repository, SCR), mediante il tool aspnet_regsql.exe, che possiamo trovare nella directory %WINDOWS%\Microsoft.NET\Framework\v2.0.50727. Lasciando come <default> la selezione del database, creeremo un DB di nome ASPNETDB nel nostro server SQL che potrà essere utilizzato per i nostri fini. A questo punto, visto che siamo nei paraggi, diamo un'occhiatina al file Machine.config che si trova nella sottodirectory CONFIG. Al suo interno possiamo trovare le seguenti parti "interessanti":

<connectionStrings>
    <add name="LocalSqlServer"
    connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true" providerName="System.Data.SqlClient" />
</connectionStrings>
...snip...
<membership>
    <providers>
        <add name="AspNetSqlMembershipProvider"
        type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral,
        PublicKeyToken=b03f5f7f11d50a3a"
        connectionStringName="LocalSqlServer"
        enablePasswordRetrieval="false"
        enablePasswordReset="true"
        requiresQuestionAndAnswer="true"
        applicationName="/"
        requiresUniqueEmail="false"
        passwordFormat="Hashed"
        maxInvalidPasswordAttempts="5"
        minRequiredPasswordLength="7"
        minRequiredNonalphanumericCharacters="1"
        passwordAttemptWindow="10"
        passwordStrengthRegularExpression="" />
    </providers>
</membership>
...snip...

Il punto su cui ragionare, in vista delle nostre applicazioni, è la ConnectionString "LocalSqlServer" e come questa viene utilizzata dal provider AspNetSqlMembershipProvider. Noi vogliamo mantenere questo provider senza apportare modifiche in ciascuna applicazione web, in modo che modificando il comportamento della membership all'interno del Machine.config, tutte le applicazioni installate sul nostro server beneficino del comportamento. Del resto è anche una questione di coerenza nelle policies di sicurezza, giusto? Preso atto di questo, creiamo una applicazione web di nome SalesApp, aggiungiamo un paio di pagine Login.aspx e Register.aspx nelle quali aggiungiamo, rispettivamente, un controllo Login ed un controllo User Creation Wizard. Nella pagina Default.aspx aggiungiamo un controllo LoginStatus e un controllo LoginName. Il pezzo forte di tutto questo, comunque è il file Web.config, che deve essere così composto:

<?xml version="1.0"?>
<configuration>
  <appSettings/>
  <connectionStrings>
    <clear/>
    
    <add name="LocalSqlServer" connectionString="SERVER=MYSERVER;DATABASE=ASPNETDB;UID=sa;PWD=password" providerName="System.Data.SqlClient" />
  </connectionStrings>
  <system.web>
    <compilation debug="false" strict="false" explicit="true" />
    <authentication mode="Forms">
      
      <forms name=".SHAREDTOKEN" loginUrl="login.aspx" protection="All"
              timeout="30"
              path="/"
              requireSSL="false"
              slidingExpiration="true"
              cookieless="UseCookies"/>
    </authentication>
    
    <machineKey validationKey="95E209A1882F59B1585FD2691BB0AEF28E8158C1CD26EADA9B2B3CF8821F2D3D39347B487F72D94E438E4EE510A730FE979A3E79D18A5DB453FE87979D25AACC" decryptionKey="B753AE2B2CEAFD2BA6B938744ECD8550ECE5F6BB51506E43" validation="SHA1" />
    
    <authorization>
      <deny users="?" />
    </authorization>
  </system.web>
</configuration>

Esaminiamo, dunque, questo file, fondamentale per il buon funzionamento della nostra "Shared-Membership"; ho modificato la stringa di connessione LocalSqlServer, in modo da farla puntare allo Shared Credential Repository creato in precedenza. Nell'elemento authentication si può vedere l'attibuto mode, impostato a Forms, ed all'interno, l'elemento forms configurato con un name, un path ed una protection ben definite. Dobbiamo fare attenzione a questi valori, perchè dovranno essere uguali in ogni applicazione che vogliamo far entrare nella nostra Shared Membership (nel club, per intenderci...). Oltre a questa impostazione, un altro elemento deve essere identico in tutte le nostre web application, ed è l'elemento machineKey. I tre attributi validationKey, decryptionKey e validation devono essere identici sempre per tutte le web app del club. Per generare valori validi riferitevi a MachineKey Generator.

A questo punto, il gioco è fatto! Per creare il primo utente, rimuovete il deny users="?" in modo da poter navigare la pagina register.aspx e create l'utente. Questo verrà creato all'interno del repository condiviso, e sarà a disposizione di tutte le applicazioni che utilizzeranno questo pattern di autenticazione condivisa. Ripristinando il deny users, la cosa simpatica è che se create un'applicazione di nome ReportApp, copiate il file web.config dalla SalesApp alla ReportApp, create un link che dalla SalesApp punti alla ReportApp e vi autenticate nella SalesApp, una volta giunti alla ReportApp, questa vi "riconoscerà" e nella pagina di default comparirà il nome del vostro utente. Stiamo quindi lavorando con un utente in un'applicazione web, essendoci autenticati presso un'altra applicazione. Estremizzando, potremmo creare un'applicazione per l'autenticazione che rinvia ad altre applicazioni concrete che implementino le funzionalità desiderate. A questo indirizzo potete trovare un semplice progetto con due applicazioni web per testare questa feature estremamente potente di ASP.net 2.0.

Nel caso in cui vogliate riportare le impostazioni del provider nel Web.Config, fate attenzione al nome dell'applicazione! Se volete condividere Membership Ruoli e Profili tra le applicazioni, dovete impostare l'attributo name allo stesso valore per ogni applicazione!

Happy authenticating!