XA.EF Entity framework (4)

Benchè nel terzo capitolo abbia speso qualche parola per la costruzione di una proprietà c'e' da aggiungere ancora molto altro. Indubbiamente mancano gli attributi, custom o dipendenti da Linq to Sql.

Verosimilmente il concetto di attributo dovrebbe essere quanto di più esplicativo per il destino della proprietà stessa, ma deve dare anche un "lume" su come potremo utilizzare la proprietà o se questa sarà visibile o meno.

Questo punto diciamo che decisamente "analitico" ossia, dato che l'implementazione è ancora molto lontana posso scegliere arbitrariamente di:

-presentare un form con tutti i campi di una tabella e attribuirgli la visibilità.
-dare la possibilità all'utente di modificare gli attributi agendo sul codice.

A ben pensarci il primo caso sembra sicuramente il più ovvio, di contro portei sfruttare quanto esposto nel post della persistenza, per avere un "registro di quanto implementato" per poi ripresentarlo all'utente che sta rigenerando le classi.

Sempre etendendo il ragionamento se genero tutto io, so che cosa ho generato. Ma gli utenti sono utenti ( e del resto anch'io ) quindi è noto il fatto che lanciato un script si ha "il prurito" di vedere che cosa è sucesso.
Quindi tanto vale lasciare la possibilità all'utente di modificare il codice generato.

Una versione semplificata di questi attributi potrebbe essere resa tramite quanto segue.

using System;

using System.ComponentModel;

using System.Collections.Generic;

using System.Linq;

using System.Text;



namespace XA.EF.Test

{



    [System.AttributeUsage(

        AttributeTargets.Class| 

        AttributeTargets.Field| 

        AttributeTargets.Property, 

        AllowMultiple = true)]

    public class DbMapperAttribute:System.Attribute

    {

        private string _dbFieldName; 

        private string _mappingEntity;

        private string _headerOrCaption;

        private eFieldVisibility _visibility;

        private int _columnOrder;



        public string dbFieldName

        {

            get { return _dbFieldName; }

        }



        public string mappingEntity

        {

            get { return _mappingEntity; }

        }



        public string headrOrCaption

        {

            get { return _headerOrCaption; }

        }



        public int columnOrder

        {

            get { return _columnOrder; }

        }



        public eFieldVisibility visibility

        {

            get { return _visibility; }

        }



        public DbMapperAttribute(

                int ColumnOrder, 

                string DbFieldName, 

                string MappingEntity, 

                string HeaderOrCaption, 

                eFieldVisibility Visibility

                )

        {

            _dbFieldName =      DbFieldName ;

            _mappingEntity =    MappingEntity;

            _headerOrCaption =  HeaderOrCaption;

            _visibility =       Visibility;

            _columnOrder =      ColumnOrder;

        }   

    }

}

e per dar maggior chiarezza, questo è l'enumerativo che utilizzo.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;



namespace XA.EF.Test

{

    public enum eFieldVisibility

    {

        none,

        grid,

        details,

        both

    }

}

Tuttavia è facile comprendere che l'attributo derivante servirà anche per mostrare o non mostrare l'elemento in una griglia o in un form di dettaglio.

Ciò detto mi è utile considerare sempre più che per la realizzazione di un E.F. strutturato e elastico è sicuramente necessario scrivere una serie di classi che vadano ben oltre alle entità.