Il web.config è nostro amico ??
Molti credo troppi, non conoscono le vere potenzialità di questo elemento. La letteratura sull'argomento è però molto molto sostanziosa.
Ma per l'appunto il web.config è davvero un nostro amico ?? SI certo che si, basta saperlo sfruttare bene.
Parafrasando i tanti esempi che si possono trovare sul web si possono ottenere mille e milli utilizzi, mille scopi e mille interpretazioni. Nel mio caso come più volte è capitato lo scopo è di presentare una funzionalità e di lasciare al lettore
la possibilità di estendere quanto ha letto con la sua realtà.
Partiamo però da una necessità:
- per un web method di un web services ci serve una particolare configurazione.
- questa è riassumibile con gli attributi "ip,hostName";
va da se che è un perfetto esempio di livello 0.
Creiamo quindi una classe che abbia quest'aspetto...
public class MySpecialConfiguration: ConfigurationSection
{
[ConfigurationProperty("IP")]
public string IP
{
get { return (string)base["IP"]; }
}
[ConfigurationProperty("hostName")]
public string hostName
{
get { return (string)base["hostName"]; }
}
}
Questa classe Estende configurationSection e aggiunge due attributi (IP, hostName).. entrambi come string..
Ora nel web Method...
MySpecialConfiguration msc = ConfigurationManager.GetSection("MySpecialConfiguration") as MySpecialConfiguration;
this.IP = msc.IP;
this.hostName = msc.hostName
tramite il configurationManager.GetSection ([nome]) recuperiamo il nome della section che ci serve.
MySpecialConfiguration msc = (MySpecialConfiguration) ConfigurationManager.GetSection("MySpecialConfiguration");
E' la stessa cosa, scegliete voi come scriverla...
E ora ... la parte clue... il web.config... ( ricordatevi che [ /] che devono essere viste come maggiore e minore...)
[configuration]
[configSections]
[section name="MySqlParameters"
type=" thisSample.MySpecialConfiguration, thisSample" /]
[/configSections]
Che cosa diavolo è type ??? thisSample.MySpecialConfiguration è il nome della classe che abbiamo implementato prima
mentre thisSample è l'assembly
Questa è la dichiarazione della nostra section, ma ci serve anche
[MySqlParameters
IP="127.0.0.1"
hostName="nudrubufu"/]
al richiamo del web method verranno letti i parametri di configurazione...
A ben pensarci questo è proprio tutto quello che serve per aggiungere le proprie "specia conf" al web conf...
martedì 16 marzo 2010
martedì 23 febbraio 2010
Web Services C# to Php Pages
Mi porto dietro quest'idea da parecchio tempo, e la teoria nasce dall'esigenza di realizzare una web application ad alta integrazione. Che sia "davvero dinamica" che possa davvero crescere, indipendentemente dalla logica, ovviando a
tutte le costrizioni che l'ambiente .Net rischia di creare.
Con costrizioni intendo "ricompilazione di tutto il sito", revisione dei puntamenti, implementazione di tanto codice per
l'ottimizzazione e tutto quello che ne è correlato.
In ambiente .Net realizzando una web application si ha come output un "sito" e pur pensando alla generallizzazione
delle primitive o dei web controls pur cercando di "disaccopiare" dati e logica, si otterà una soluzione dove per aggiungere
pagine si è costretti a ricompilare tutto.
Ho quindi pensato di Staccare il "sito" da chi fornisce i dati, e chi segue il mio blog, si sarà accorto che soprattutto negli
ultimi post ho fatto qualche breve analisi su quel che mi poteva servire...
Ho pensato ad una Business Logic realizzato da web services in c# e le web page realizzate in php.
Grazie a jQuery è possibile "con uno sforzo iniziale un po' più sostanzioso" ottenere dei risultati decisamente buoni.
Il concetto di base è semplice:
php web page in post chiamata ajax ottiene l'xml dal web services.
E' possibile che la pagina contenga oggetti php che sappiano tradurre l'xml in quanto serve realmente mostrare.
Va da se che oggi l'esecutore della chiamata è una pagina php, ma parlando per Astrazioni è possibile che l'inteprete
dell'xml possa essere qualsiasi altra "Entità".
Integrazione con il project management... In perfetto stile "Agile" sfruttando questa logica d'implementazione si
ha un altro grosso vantaggio. Ogni funzionalità è "FINALIZZATA" è può essere verificata / testa / accettata / chiusa
senza impatti sul resto della soluzione.
Volete saperne di più ? contattatemi via mail.
tutte le costrizioni che l'ambiente .Net rischia di creare.
Con costrizioni intendo "ricompilazione di tutto il sito", revisione dei puntamenti, implementazione di tanto codice per
l'ottimizzazione e tutto quello che ne è correlato.
In ambiente .Net realizzando una web application si ha come output un "sito" e pur pensando alla generallizzazione
delle primitive o dei web controls pur cercando di "disaccopiare" dati e logica, si otterà una soluzione dove per aggiungere
pagine si è costretti a ricompilare tutto.
Ho quindi pensato di Staccare il "sito" da chi fornisce i dati, e chi segue il mio blog, si sarà accorto che soprattutto negli
ultimi post ho fatto qualche breve analisi su quel che mi poteva servire...
Ho pensato ad una Business Logic realizzato da web services in c# e le web page realizzate in php.
Grazie a jQuery è possibile "con uno sforzo iniziale un po' più sostanzioso" ottenere dei risultati decisamente buoni.
Il concetto di base è semplice:php web page in post chiamata ajax ottiene l'xml dal web services.
E' possibile che la pagina contenga oggetti php che sappiano tradurre l'xml in quanto serve realmente mostrare.
Va da se che oggi l'esecutore della chiamata è una pagina php, ma parlando per Astrazioni è possibile che l'inteprete
dell'xml possa essere qualsiasi altra "Entità".
Integrazione con il project management... In perfetto stile "Agile" sfruttando questa logica d'implementazione si
ha un altro grosso vantaggio. Ogni funzionalità è "FINALIZZATA" è può essere verificata / testa / accettata / chiusa
senza impatti sul resto della soluzione.
Volete saperne di più ? contattatemi via mail.
lunedì 22 febbraio 2010
Div posizioni assolute e relative.....
Comprendo (div)entar matti, ma esagerare non fa bene alla salute.
Questo mini tutorial vi spiega come funzionano i vari allineamenti sfruttando
css Position.
Partiamo da una cosa semplice
Per ottenere questa pagina vi basta realizzare 4 div
1) {width:100%;height:100%}
2) {margin:0 auto;width:960px;background-color:yellow;}
3) {width:100px;height:100px;background-color:red;}
4) {width:100px;height:100px;background-color:lime;}
1) contiene 2)
2) contiene 3) e 4)
così:
Spostiamo il blocco verde
1) {width:100%;height:100%}
2) {margin:0 auto;width:960px;background-color:yellow;}
3) {width:100px;height:100px;background-color:red;float:left}
4) {width:100px;height:100px;background-color:lime;}
Spostiamo il Rosso al posto del verde
1) {width:100%;height:100%}
2) {margin:0 auto;width:960px;background-color:yellow;}
3) {width:100px;height:100px;background-color:red;float:right}
4) {width:100px;height:100px;background-color:lime;}
Rosso e verde uno sull'altro ..
1) {width:100%;height:100%}
2) {margin:0 auto;width:960px;background-color:yellow;}
3) {position:absolute;left:50;width:100px;height:100px;background-color:red;}
4) {width:100px;height:100px;background-color:lime;}
Rosso e verde uno sull'altro, ma in un altro modo.
1) {width:100%;height:100%}
2) {position:relative;margin:0 auto;width:960px;background-color:yellow}
3) {position:absolute;width:100px;height:100px;background-color:red;}
4) {position:absolute;top:10;width:100px;height:100px;background-color:lime;}
Non c'e' troppa chiarezza, quanto meno non è sempre specificato dove Mettere il RELATIVE. Ho fatto parecchie prove prima
di questo mini tutorial per comprendere quanto le posizioni siano "evanescenti".
Specificando nel div contenitore 2) il relative implica che tutti i div ( conenuti e con stile absolute ) faranno riferimento
alla posizione 0,0 (angolo in alto a sinitra).
Tutto quello che contine d4 non subirà variazioni, ma seguira la posizione in cui questo si trova.
Questo mini tutorial vi spiega come funzionano i vari allineamenti sfruttando
css Position.
Partiamo da una cosa semplice
Per ottenere questa pagina vi basta realizzare 4 div
1) {width:100%;height:100%}
2) {margin:0 auto;width:960px;background-color:yellow;}
3) {width:100px;height:100px;background-color:red;}
4) {width:100px;height:100px;background-color:lime;}
1) contiene 2)
2) contiene 3) e 4)
così:
Spostiamo il blocco verde1) {width:100%;height:100%}
2) {margin:0 auto;width:960px;background-color:yellow;}
3) {width:100px;height:100px;background-color:red;float:left}
4) {width:100px;height:100px;background-color:lime;}
Spostiamo il Rosso al posto del verde
1) {width:100%;height:100%}
2) {margin:0 auto;width:960px;background-color:yellow;}
3) {width:100px;height:100px;background-color:red;float:right}
4) {width:100px;height:100px;background-color:lime;}
Rosso e verde uno sull'altro ..1) {width:100%;height:100%}
2) {margin:0 auto;width:960px;background-color:yellow;}
3) {position:absolute;left:50;width:100px;height:100px;background-color:red;}
4) {width:100px;height:100px;background-color:lime;}
Rosso e verde uno sull'altro, ma in un altro modo.1) {width:100%;height:100%}
2) {position:relative;margin:0 auto;width:960px;background-color:yellow}
3) {position:absolute;width:100px;height:100px;background-color:red;}
4) {position:absolute;top:10;width:100px;height:100px;background-color:lime;}
Non c'e' troppa chiarezza, quanto meno non è sempre specificato dove Mettere il RELATIVE. Ho fatto parecchie prove prima
di questo mini tutorial per comprendere quanto le posizioni siano "evanescenti".
Specificando nel div contenitore 2) il relative implica che tutti i div ( conenuti e con stile absolute ) faranno riferimento
alla posizione 0,0 (angolo in alto a sinitra).
Tutto quello che contine d4 non subirà variazioni, ma seguira la posizione in cui questo si trova.
giovedì 18 febbraio 2010
Decorator
Fra tanti pattern utili il decorator troneggia, anche se potrebbe non esser sempre chiaro lo scopo, o dove come quando applicarlo.Tecnicamente parlando il decorator non fa altro che "estendere una base" e aggiungere "qualcosa".
Nel caso in esempio, esiste una classe Generic Item che è descritta da due proprietà e due metodi.
Le proprietà appartengono a Generic Item
I metodi sono virtuali (ossia) esiste la firma e volendo il codice del metodo, ma potrà essere esteso.
La classe book, estende Generic Item aggiunge due proprietà ed esegue l'override dei due metodi.
La classe brochure , estende Generic Item aggiunge una proprietà ed esegue l'override dei due metodi.
E' pur logico che il modo di Editare un libro sia diverso dal modo di Editare una brochure e tanto vale anche
per il modo in cui esse verranno visualizzati.
La classe astratta decorator ha un compito Creare Oggetti che abbiano come BASE Generic Item.
La classe coDecorator effettuerà il management di ciò che il decorator ha creato.
Ciò Detto ..
E' facile intuire quanto sia semplice individuare i casi d'uso, il rischio e che offuscati dalla voglia di utilizzare questo
pattern lo si "infili" un po da tutte le parti.
Un caso comune potrebbe essere la necessità di aggregare ad una classe Entity le sue derivate.
Utente e Utente Esteso
la classe utente (la nostra Generic Item ) contiene Nome Cognome, Login, Password
la classe utente Esteso (la nostra brochure o book) contiene in più Numero matricola, interno telefonico, sede di lavoro...
I dati della prima classe risiedono sulla tabelle Utenti mentre i dati di utente esteso potrebbero provenire da Ldap.
Per cui in Decorator creeremo UtenteEsteso e in coDecorator Popoleremo i dati.
WHERE 1=1
Per meglio dire quando barare via SQL.
Supponiamo che per un motivo qualsiasi abbiate realizzato un QueryHelpers che fra i suo metodi presenti AddContidion
e (sempre basandoci su una supposizione) la firma sia simle a questa:
public static string AddCondition(string OriginlQuery, string fieldName, string fieldValue, string Caluse)
Supponiamo (sempre) che il metodo verifichi prima che la sintassi sia corretta, che poi aggiunga la condizione
costruita più o meno così Caluse fieldName = fieldValue
dove Caluse può essere AND OR
Questo metodo potrebbe andare più o meno sempre... e per altro Va, ma davanti a query un po più complesse, si presentano
i primi problemi..
se per esempio ci si imbatte in query tipo :
select * from ( select * from blabla union select * from blabla ) as myBlabla
il rischio è che si debba valutare l'apertura di parentesi la chiusura e il breve parser fatto con affetto va a ramengo.
Torna comodo sapere ANCHE SE E' UN TRUCCO VECCHIO e stra VECCHIO, che ogni tanto si può far credere ai
vari "db engine" che stanno facendo qualcosa di utilmente inutile.
SELECT * FROM utenti WHERE 1=1 equivale per esempio a SELECT * FROM utenti.
Certo è vero equivalgono per risultati .. ma in tempi macchina ?? o cicli che dir si voglia ??
Su estrazioni piccole la differenza è minima (1000 rec), su estrazioni grosse(100000 rec) il peso si inizia a notare,
ma la cosa varia da db engine a db engine.
Supponiamo che per un motivo qualsiasi abbiate realizzato un QueryHelpers che fra i suo metodi presenti AddContidion
e (sempre basandoci su una supposizione) la firma sia simle a questa:
public static string AddCondition(string OriginlQuery, string fieldName, string fieldValue, string Caluse)
Supponiamo (sempre) che il metodo verifichi prima che la sintassi sia corretta, che poi aggiunga la condizione
costruita più o meno così Caluse fieldName = fieldValue
dove Caluse può essere AND OR
Questo metodo potrebbe andare più o meno sempre... e per altro Va, ma davanti a query un po più complesse, si presentano
i primi problemi..
se per esempio ci si imbatte in query tipo :
select * from ( select * from blabla union select * from blabla ) as myBlabla
il rischio è che si debba valutare l'apertura di parentesi la chiusura e il breve parser fatto con affetto va a ramengo.
Torna comodo sapere ANCHE SE E' UN TRUCCO VECCHIO e stra VECCHIO, che ogni tanto si può far credere ai
vari "db engine" che stanno facendo qualcosa di utilmente inutile.
SELECT * FROM utenti WHERE 1=1 equivale per esempio a SELECT * FROM utenti.
Certo è vero equivalgono per risultati .. ma in tempi macchina ?? o cicli che dir si voglia ??
Su estrazioni piccole la differenza è minima (1000 rec), su estrazioni grosse(100000 rec) il peso si inizia a notare,
ma la cosa varia da db engine a db engine.
martedì 16 febbraio 2010
Per non perdere il focal point....
In troppi casi, nel nostro lavoro, rischiamo di perdere concentrazione o di allontanarci dalla soluzione. Le cause ? generalmente quisquiglie, rumore, pressione...
Il risultato... classi che fanno la stessa cosa, uno sproposito di righe di codici perfettamente inutili che appesantiscono notevolmente le prestazioni del prodotto finale.
E' possibile ovviare a questo problema ? di metodi ce ne sono tanti e ogniuno ha il suo, e per ogniuno può essere più o meno complesso.
Io mi sono fatto un schema, sul design pattern che più volte mi è tornato utile e più che altro mi serve per ragionare e soffermarmi su quello che sto facendo.
Intent
che cosa fa / o che cosa deve fare ?
Also konw as well
ho già fatto altro o esiste qualcosa di simile ?
Motivation / scenario
Uno scenario / disegno che illustra il problema e come gli oggetti lo risolvano
Applicability
In quali situazioni è applicabile il Design pattern ? Esistono esempi ? Come riconoscere le situazioni.
Structure
una rappresentazione grafica basata sulla notazione Object modelling
Partecipants
Le classi e gli oggetti che partecipano al pattern e le loro responsabilità.
Collaboration
Come le classi e gli oggetti collaborano per conncorrere alle loro responsabilità.
Consequences
Che cosa comporta l utilizzo del pattern in questione, quali sono i limiti e le sue dipendenze.
Implementation
Quali sono i limiti imposti nell'implementazione ?
Sample Code
una porzione di codice che chiarisca come implementare il codice nel linguaggio.
Konow Use
un esempio nel mondo reale del pattern in oggetto
Related Patterns
Ci sono altri pattern che definisco la soluzione? E possibile che questo debba o possa interagire con altri pattern?
Ora non ricordo se questa è una rielaborazione di un qualcosa che avevo trovato sul web tempo fa, ma l'adotto e ritengo che sia parecchio parecchio utile.
Il risultato... classi che fanno la stessa cosa, uno sproposito di righe di codici perfettamente inutili che appesantiscono notevolmente le prestazioni del prodotto finale.
E' possibile ovviare a questo problema ? di metodi ce ne sono tanti e ogniuno ha il suo, e per ogniuno può essere più o meno complesso.
Io mi sono fatto un schema, sul design pattern che più volte mi è tornato utile e più che altro mi serve per ragionare e soffermarmi su quello che sto facendo.
Intent
che cosa fa / o che cosa deve fare ?
Also konw as well
ho già fatto altro o esiste qualcosa di simile ?
Motivation / scenario
Uno scenario / disegno che illustra il problema e come gli oggetti lo risolvano
Applicability
In quali situazioni è applicabile il Design pattern ? Esistono esempi ? Come riconoscere le situazioni.
Structure
una rappresentazione grafica basata sulla notazione Object modelling
Partecipants
Le classi e gli oggetti che partecipano al pattern e le loro responsabilità.
Collaboration
Come le classi e gli oggetti collaborano per conncorrere alle loro responsabilità.
Consequences
Che cosa comporta l utilizzo del pattern in questione, quali sono i limiti e le sue dipendenze.
Implementation
Quali sono i limiti imposti nell'implementazione ?
Sample Code
una porzione di codice che chiarisca come implementare il codice nel linguaggio.
Konow Use
un esempio nel mondo reale del pattern in oggetto
Related Patterns
Ci sono altri pattern che definisco la soluzione? E possibile che questo debba o possa interagire con altri pattern?
Ora non ricordo se questa è una rielaborazione di un qualcosa che avevo trovato sul web tempo fa, ma l'adotto e ritengo che sia parecchio parecchio utile.
lunedì 15 febbraio 2010
Test-Driven ? Yes...
Come per tutte i concetti o paradigmi o metodologie, nell'ambito informatico tutto è astratto e tutto può essere applicato a diversi concetti.
Affrontando soluzioni in D.D.D, emerge subito il concetto di Test-Driven, ma è contestualizzabile solo per il D.D.D. ? Secondo me il concetto è decisamente astratto...
Parafrasando l'esempio banale la realizzazione di una calcolatrice, sia l'analista che il programmatore, daranno per scontato che al primo avvio non si verifichino problemi, poi basta premere una lettera al posto di un numero... e puf ci becchiamo un eccezione...
Questo perchè ? Semplice Troppe volte ci si dimentica di testare tutto il nostro codice... no.
Questo avviene perchè non è chiaro lo scopo di quello che stiamo facendo.
E gli elementi "di base" che il più delle volte diamo per scontati non sono stati presi in considerazione.
Il paradigma del T-D è che si deve testare una funzionalità per volta e che il test deve essere ripetibile e che il test deve essere positivo prima di aver scritto il codice...
Ma davvero ?? Si Tornando alla nostra calcolatrice, se la pressione del bottone 1 deve scatenare
la scrittura del testo 1 nella casella di testo e popolare un buffer, già sappiamo che cosa non dovrà fare il bottone 1...
Interpretando quindi il T-D è utile sapere e implementare il codice affinche la pressione del bottone 1 corrisponda solo a quell'azione...
Detto così forse è anche troppo semplice, ma il concetto di base è questo.
Affrontando soluzioni in D.D.D, emerge subito il concetto di Test-Driven, ma è contestualizzabile solo per il D.D.D. ? Secondo me il concetto è decisamente astratto...
Parafrasando l'esempio banale la realizzazione di una calcolatrice, sia l'analista che il programmatore, daranno per scontato che al primo avvio non si verifichino problemi, poi basta premere una lettera al posto di un numero... e puf ci becchiamo un eccezione...
Questo perchè ? Semplice Troppe volte ci si dimentica di testare tutto il nostro codice... no.
Questo avviene perchè non è chiaro lo scopo di quello che stiamo facendo.
E gli elementi "di base" che il più delle volte diamo per scontati non sono stati presi in considerazione.
Il paradigma del T-D è che si deve testare una funzionalità per volta e che il test deve essere ripetibile e che il test deve essere positivo prima di aver scritto il codice...
Ma davvero ?? Si Tornando alla nostra calcolatrice, se la pressione del bottone 1 deve scatenare
la scrittura del testo 1 nella casella di testo e popolare un buffer, già sappiamo che cosa non dovrà fare il bottone 1...
Interpretando quindi il T-D è utile sapere e implementare il codice affinche la pressione del bottone 1 corrisponda solo a quell'azione...
Detto così forse è anche troppo semplice, ma il concetto di base è questo.
Iscriviti a:
Post (Atom)