Design
There are 7 entries for the tag
Design
La scorsa settimana durante una code review, mi sono imbattuto in questo pezzo di codice (ho tolto alcune parti per non allungare troppo il post): // [Cut]
case USER_AGENT:
// [Cut]...various code....
goto default; //we want it to be added to serverVariables
case CONTENT_TYPE:
// [Cut]...more code (with some "if")
goto default; //we want it to be added to serverVariables
case USER_LANGUAGE:
ParseUserLanguage(variableValue);
break;
default:
ServerVariables.Add(variableName, variableValue);
...
Le famose 3R del motto Reduce Reuse Recycle sono molto utilizzate in ambito ambientalista ma possono essere applicate anche al mondo della programmazione. Un buon programmatore è attento all'ecologia della propria applicazione visto che il codice che la compone è l'ambiente in cui passa molto del suo tempo lavorativo. Se l'applicazione è sviluppata rispettando l'ambiente nel quale gira è sicuramente un vantaggio per l'intero ecosistema virtuale. Reduce: ridurre il codice. Sembrerà strano ma spesso è più difficile cancellare codice che aggiungerne di nuovo. Aggiungere troppo codice è spesso frutto overengineering che porta ad implementare funzionalità non strettamente necessarie e...
Ribaltamento della prospettiva nel creare applicazioni. Dal DB all'interfaccia e viceversa
Quale approccio usate nello sviluppo delle applicazioni?
Anni fa per me era un must che lo sviluppo di una nuova applicazione iniziasse dal database e su quello si iniziasse a disegnare il DAL per risalire fino all'interfaccia utente. Per questo i primi giorni erano dedicati al design e all'implementazione di un primo prototipo di database.
Quello che ottenevo era un modello basato sul "Transaction Script" o sul Table Data Gateway con i loro vantaggi e svantaggi.
A quel tempo la parte più importante dell'applicazione era il database.
Il problema di questo approccio bottom-up è...
Con l'arrivo di VS2003 MS ha introdotto le region all'interno dell'IDE.
Non sono mai stato un grande utilizzatore di questa feature ma troppo spesso la vedo utilizzata nel modo sbagliato.
Quasi sempre sono usate per separare le proprietà dai metodi privati , dai metodi pubblici, dai costruttori, ecc…
Quindi apro una classe e vedo:
Che valore mi danno quelle region? NESSUNO!
Non sarebbe meglio suddividere il codice invece che per visibilità o tipo di elemento per funzionalità (metodi che fanno questo, metodi che fanno quello)?
Sarebbe un primo passo. Poi se la classe è ben disegnata e scritta in modo elegante ci accorgeremmo che le...
Claudio mi ha anticipato di qualche ora.
Nel suo post spiega che LINQ non è solo un "linguaggio" (o dovremmo chiamarla sintassi?) per interrogare fonti dati è anche un ottimo strumento per scrivere codice più sintetico e più "parlante".
Io vorrei riprendere (questa è davvero l'ultima :-)) il discorso sui DTO.
Con LINQ molti dei discorsi fatti decadono, infatti non è più necessario scrivere classi ad-hoc per creare oggetti DTO (o oggetti Vista), LINQ permette di creare oggetti on-the-fly con la forma che ci serve per quel preciso contesto.
Riprendiamo il solito esempio Customer-Address in cui vogliamo mostrare a video un elenco di Customer...
Questo post chiude il giro sui DTO (o ViewObjects).
Nello scorso post abbiamo visto una soluzione sufficientemente elegante per implementare dei DTO usando delle classi Wrapper attorno agli oggetti del DM.
Tale soluzione è per quel che ho visto la più utilizzata ma in questo post vorrei mostrare una terza implementazione possibile.
L'unica pecca della soluzione precedente della classe wrapper è che il DTO dipende dall'oggetto del DM in quanto al suo interno ha un riferimento alla classe Employee.
Per svincolarci anche da questo legame possiamo costruire una classe che contiene solo le proprietà da portare sull'interfaccia senza però dipendere dal DM. Ad esempio:
...
Nell'ultimo post abbiamo implementato un semplice DTO sfruttando l'ereditarietà ma ci siamo accorti di alcuni problemi che la soluzione porta con se. In chiusura abbiamo citato il principio "Favor encapsulation over inheritance".
Cosa vuol dire?
Vuol dire che il DTO invece di ereditare da Employee lo dovrebbe incapsulare.
Vediamo il codice:
public class EmployeeDTO
{
private Employee _employee;
public EmployeeDTO(Employee employee)
{
_employee = employee;
}
public String Name
{
...