Con l'avvento su scala globale di HTML5 le tecnologie web si sono evolute cercando di offrire all'utente una migliore esperienza applicativa sempre più simile a quella desktop. Sul piano tecnico questo viene realizzato spostando la logica di presentazione sul browser client facendo leva su Javascript e CSS3. In questa sessione vedremo come KnockoutJS, un presentation framework Javascript basato sul pattern Model-View-ViewModel, permette di sviluppare Rich Internet Application (RIA) analizzando le sue caratteristiche implementative e mostrando esempi di casi reali anche in ambito mobile.
Javascript avanzato: sfruttare al massimo il webRoberto Messora
Javascript è uno dei linguaggi più sottovalutati e più incompresi dell'intero panorama dei linguaggi di programmazione, eppure è anche uno dei più utilizzati.
Da una parte le molteplici e differenti declinazioni degli strumenti di navigazione web, dall'altra l'infelice scelta storica di usare il termine "script", hanno contribuito alla creazione del mito di un linguaggio poco rigoroso, al servizio di ogni sorta di trucco o pezza di codice.
La verità invece racconta di un linguaggio dinamico ad oggetti a tutti gli effetti, con caratteristiche molto interessanti, seppur con qualche difetto, ma soprattutto un linguaggio che, sull'onda di HTML5, rivestirà se possibile ancora più importanza nell'immediato futuro.
In questa sessione verranno presentati aspetti poco conosciuti, ma molto importanti, di Javascript (scoping, hoisting, closures, ecc.), verranno presentati alcuni design patterns che permettono di strutturare in maniera intelligente le nostre librerie applicative in funzione della manutenibilità e delle performance, senza tralasciare, ove possibile, uno sguardo ad alcuni framework come jQuery o KnockoutJS.
Con l'avvento su scala globale di HTML5 le tecnologie web si sono evolute cercando di offrire all'utente una migliore esperienza applicativa sempre più simile a quella desktop. Sul piano tecnico questo viene realizzato spostando la logica di presentazione sul browser client facendo leva su Javascript e CSS3. In questa sessione vedremo come KnockoutJS, un presentation framework Javascript basato sul pattern Model-View-ViewModel, permette di sviluppare Rich Internet Application (RIA) analizzando le sue caratteristiche implementative e mostrando esempi di casi reali anche in ambito mobile.
Javascript avanzato: sfruttare al massimo il webRoberto Messora
Javascript è uno dei linguaggi più sottovalutati e più incompresi dell'intero panorama dei linguaggi di programmazione, eppure è anche uno dei più utilizzati.
Da una parte le molteplici e differenti declinazioni degli strumenti di navigazione web, dall'altra l'infelice scelta storica di usare il termine "script", hanno contribuito alla creazione del mito di un linguaggio poco rigoroso, al servizio di ogni sorta di trucco o pezza di codice.
La verità invece racconta di un linguaggio dinamico ad oggetti a tutti gli effetti, con caratteristiche molto interessanti, seppur con qualche difetto, ma soprattutto un linguaggio che, sull'onda di HTML5, rivestirà se possibile ancora più importanza nell'immediato futuro.
In questa sessione verranno presentati aspetti poco conosciuti, ma molto importanti, di Javascript (scoping, hoisting, closures, ecc.), verranno presentati alcuni design patterns che permettono di strutturare in maniera intelligente le nostre librerie applicative in funzione della manutenibilità e delle performance, senza tralasciare, ove possibile, uno sguardo ad alcuni framework come jQuery o KnockoutJS.
Vedremo come sfruttare le potenzialità di WPF per realizzare applicazioni diverse dalle classiche LOB (Line of Business applications), basandosi su 3D e Natural User Interface.
Cos'è la UI Composition e che problemi può risolvere
Perchè MVVM e WPF sono importanti per la UI Composition
Il concetto di 'region' e 'UI Injection'
Analisi del toolkit PRISM di Microsoft e cosa comporta realizzarsene uno in proprio.
Iter documentale per gli iscritti alla sezione E del RUI (collaborazione con ...Fabrizio Callarà
Iter documentale per gli iscritti alla sezione E del RUI (collaborazione con Agenzie organizzate al Plurimandato Orizzontale) di Rolando Martorelli, Consigliere di Amministrazione delegato alla Formazione ISVAP ed alla "Compliance" di AEC Underwriting Agenzia di Assicurazione e Riassicurazione SpA. Agenzia di sottoscrizione indipendente dedicata al collocamento dei "Rischi Professionali" sul mercato internazionale
Slide Tesi di laurea:
Separazione dei ruoli tra Designer e Developer nello sviluppo di applicazioni Desktop: uso di WPF e del pattern Model-View-ViewModel
ASP.NET MVC è una piattaforma aperta costruita come un puzzle di componenti. Per personalizzare il comportamento dei componenti interni del sistema è quindi sufficiente rimuovere uno dei tasselli e sostituirlo con uno scritto da noi. Un'operazione resa semplice ed immediata dall'interfaccia Dependency Resolver.
Quando ci si trova nella necessità di sviluppare applicazioni per Microsoft Windows Phone più complesse, l'approccio tradizionale mostra qualche limite: non c'è una separazione tra i vari strati dell'applicazione e il codice è più difficile da testare e da mantenere. Questo webinar vi mostrerà le basi del pattern Model-View-ViewModel (MVVM), che offre un approccio più strutturato, in grado di separare la parte di logica dall'interfaccia grafica. / When you need to develop complex applications for Microsoft Windows Phone, the traditional approach shows some limitations. This webinar will show you the basics of Model-View-ViewModel (MVVM), which offers a more structured approach.
OVERVIEW: Java secondo Microsoft
STRUMENTI:Java nel cloud
MODALITA’: Il Development life cycle secondo Microsoft
APPROCCIO: Stack cloud native basato su JAVA ed Azure
CAMBIAMENTO: Know how necessario per lo sviluppo su AZURE con Java
OPPORTUNITA: Use case di implementazione «first approach»
TYPESCRIPT, ANGULAR E BOOTSTRAP ASSIEME PER APPLICAZIONI REAL WORLDDotNetCampus
La recente affermazione in ambito web delle applicazioni rich basate su HTML5 e Javascript è diventato sorgente di una serie di librerie innovative e di strumenti che, se usati correttamente, possono semplificare enormemente lo sviluppo. In questa sessione sarà illustrato come sfruttare Typescript, in concomitanza con Angular e Bootstrap per realizzare applicazioni che sfruttino al massimo le possibilità dei browser e diano un feedback il più possibile simile alle applicazioni desktop.
Power BI: Introduzione ai dataflow e alla preparazione dei dati self-serviceMarco Pozzan
Power BI Dataflow è il componente di trasformazione dei dati in Power BI. È un processo di Power Query che viene eseguito nel cloud. Bene, questa potrebbe non sembrare una funzionalità molto nuova, giusto? Quindi cosa c'è di nuovo con Dataflow? Le risposte alle vostre domande saranno nella mia sessione :-)
Polyglot Persistance con PostgreSQL, CouchDB, MongoDB, Redis e OrientDBSteve Maraspin
Pirma parte del seminario su NoSQL al DiTeDi di Udine del 15/12/2012. Affrontato il caso di studio di un'architettura enterprise, basata su datastore relazionali (PostgreSQL) e non (CouchDB, MongoDB, Redis e OrientDB).
Vedremo come sfruttare le potenzialità di WPF per realizzare applicazioni diverse dalle classiche LOB (Line of Business applications), basandosi su 3D e Natural User Interface.
Cos'è la UI Composition e che problemi può risolvere
Perchè MVVM e WPF sono importanti per la UI Composition
Il concetto di 'region' e 'UI Injection'
Analisi del toolkit PRISM di Microsoft e cosa comporta realizzarsene uno in proprio.
Iter documentale per gli iscritti alla sezione E del RUI (collaborazione con ...Fabrizio Callarà
Iter documentale per gli iscritti alla sezione E del RUI (collaborazione con Agenzie organizzate al Plurimandato Orizzontale) di Rolando Martorelli, Consigliere di Amministrazione delegato alla Formazione ISVAP ed alla "Compliance" di AEC Underwriting Agenzia di Assicurazione e Riassicurazione SpA. Agenzia di sottoscrizione indipendente dedicata al collocamento dei "Rischi Professionali" sul mercato internazionale
Slide Tesi di laurea:
Separazione dei ruoli tra Designer e Developer nello sviluppo di applicazioni Desktop: uso di WPF e del pattern Model-View-ViewModel
ASP.NET MVC è una piattaforma aperta costruita come un puzzle di componenti. Per personalizzare il comportamento dei componenti interni del sistema è quindi sufficiente rimuovere uno dei tasselli e sostituirlo con uno scritto da noi. Un'operazione resa semplice ed immediata dall'interfaccia Dependency Resolver.
Quando ci si trova nella necessità di sviluppare applicazioni per Microsoft Windows Phone più complesse, l'approccio tradizionale mostra qualche limite: non c'è una separazione tra i vari strati dell'applicazione e il codice è più difficile da testare e da mantenere. Questo webinar vi mostrerà le basi del pattern Model-View-ViewModel (MVVM), che offre un approccio più strutturato, in grado di separare la parte di logica dall'interfaccia grafica. / When you need to develop complex applications for Microsoft Windows Phone, the traditional approach shows some limitations. This webinar will show you the basics of Model-View-ViewModel (MVVM), which offers a more structured approach.
OVERVIEW: Java secondo Microsoft
STRUMENTI:Java nel cloud
MODALITA’: Il Development life cycle secondo Microsoft
APPROCCIO: Stack cloud native basato su JAVA ed Azure
CAMBIAMENTO: Know how necessario per lo sviluppo su AZURE con Java
OPPORTUNITA: Use case di implementazione «first approach»
TYPESCRIPT, ANGULAR E BOOTSTRAP ASSIEME PER APPLICAZIONI REAL WORLDDotNetCampus
La recente affermazione in ambito web delle applicazioni rich basate su HTML5 e Javascript è diventato sorgente di una serie di librerie innovative e di strumenti che, se usati correttamente, possono semplificare enormemente lo sviluppo. In questa sessione sarà illustrato come sfruttare Typescript, in concomitanza con Angular e Bootstrap per realizzare applicazioni che sfruttino al massimo le possibilità dei browser e diano un feedback il più possibile simile alle applicazioni desktop.
Power BI: Introduzione ai dataflow e alla preparazione dei dati self-serviceMarco Pozzan
Power BI Dataflow è il componente di trasformazione dei dati in Power BI. È un processo di Power Query che viene eseguito nel cloud. Bene, questa potrebbe non sembrare una funzionalità molto nuova, giusto? Quindi cosa c'è di nuovo con Dataflow? Le risposte alle vostre domande saranno nella mia sessione :-)
Polyglot Persistance con PostgreSQL, CouchDB, MongoDB, Redis e OrientDBSteve Maraspin
Pirma parte del seminario su NoSQL al DiTeDi di Udine del 15/12/2012. Affrontato il caso di studio di un'architettura enterprise, basata su datastore relazionali (PostgreSQL) e non (CouchDB, MongoDB, Redis e OrientDB).
Cos'è la UI Composition e che problemi può risolvere
Perchè MVVM e WPF sono importanti per la UI Composition
Il concetto di 'region' e 'UI Injection'
Analisi del toolkit PRISM di Microsoft e cosa comporta realizzarsene uno in proprio.
This set of design patterns are related to Enterprise Patterns. In it you can find, J2EE, Presentation, Business & Integration Patterns (such as: ApplicaCon Controller, Data Transfer Object (DTO), Business Object (BO) & Data Access Object (DAO) among others ...)
L'Internet of Things è una realtà e primo o dopo avrà il suo impatto significativo nelle nostre aziende.
E a quel punto, i device saranno un asset di cui gestire il lifetime, alla pari dei nostri server, reti e cloud.
Azure IoT è la piattaforma su cui possiamo sviluppare la nostra soluzione IoT e cerchiamo di comprendere cosa significa amministrare un parco device.
Alcuni temi: protocolli di comunicazione e sicurezza del device e della comunicazione. Provisioning dei device. Gestione e monitoraggio dei dispositivi. Strumenti ed API a disposizione per l'IT Pro.
Back to the Future: Migrare da WebForm ad ASP.NET Core gradualmente Andrea Dottor
Molte applicazione sono (ancora) sviluppate in WebForm e non possono essere convertite automaticamente ad ASP.NET Core. Una riscrittura completa in molti casi è impossibile o impensabile da attuare. In questa sessione vedremo come migrare in modo graduale queste tipologie di applicazioni verso ASP.NET Core, andando in dettaglio nelle varie problematiche che solitamente si possono presentare. La sessione deriva da un'esperienza reale, che ha permesso di conoscere (nel bene o nel male) le difficoltà che si nascondo in queste migrazioni.
Evento: https://www.xedotnet.org/eventi/one-day-enterprise-application/
Welcome to the (state) machine @ ExploreDDD 2019Mauro Servienti
Stateless all the thing, they say. In the last few years we’ve been brainwashed: design stateless systems, otherwise they cannot scale, they cannot be highly available, and they are hard to maintain and evolve. In a nutshell stateful is bad. However complex software systems need to do collaborative processing, that is stateful by definition. Stateless myth busted! Collaborative domains deal with long running business transactions and need to interact with distributed resources. The traditional distributed transactions approach, even if tempting, is a time bomb.
This is when Sagas come into play. Sagas allow to model complex collaborative domains without the need for distributed transactions and/or orchestration across multiple resources. Join Mauro on a journey that aims to disclose what sagas are, how they can be used to model a complex collaborative domain, and what role they play when it comes to designing systems with failure and eventual consistency in mind.
(It’s all right, I know where you’ve been)
Designing a ui for microservices @ .NET Day Switzerland 2019Mauro Servienti
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Welcome to the (state) machine @ Xe One Day Enterprise ApplicationsMauro Servienti
Ultimamente ci hanno stressato come non mai che stateful è il male. Tutto deve essere stateless, altrimenti non scala, non può essere altamente disponibile, ed è complesso da manutenere ed evolvere. Nonostante questo i sistemi software complessi, essendo basati su processi collaborativi, sono per natura stateful. I processi collaborativi, noti anche come long running business transactions, necessitano di interagiscono con risorse distribuite. L’approccio tradizionale basato su transazioni distribuite, anche se allettante, è una bomba pronta ad esplodere.
Pane quotidiano per le Saghe. Le Saghe consentono di modellare sistemi complessi senza la necessità di transazioni distribuite e coordinamento esterno. Vedremo cosa sono le Saghe, come possono essere usate per modellare domini complessi, e che ruolo giocano quando progettiamo sistemi basati sui concetti di “design for failures” e “eventual consistency”
(It’s all right, I know where you’ve been)
All our aggregates are wrong @ NDC Copenhagen 2019Mauro Servienti
It always starts well. At first glance the requirements seem straightforward, and implementation proceeds without hiccups. Then the requirements start to get more complex, and you find yourself in a predicament, introducing technical shortcuts that smell for the sake of delivering the new feature on schedule.
In this talk, we’ll analyze what appears to be a straightforward e-commerce shopping cart. We’ll then go ahead and add a few more use-cases that make it more complex and see how it can negatively impact the overall design. Finally, we’ll focus our attention to the business needs of these requirements and see how it can shed light on the correct approach to designing the feature. Walk away with a new understanding on how to take requirements apart to build the right software.
Be like water, my friend @ Agile for Innovation 2019Mauro Servienti
L’acqua è quasi inarrestabile, basta un pertugio e si propaga. Basta un po’ di pressione e con facilità il pertugio diventa una voragine e lascia spazio ad una piena. La conoscenza e l’esperienza in un team possono essere come l’acqua. Il sapere deve poter scorrere senza freni, con solo degli argini che lo guidino al fine di evitare un’inondazione.
È possibile strutturare un’organizzazione al fine di garantire la diffusione del sapere? Quali sono i processi e gli strumenti che possiamo mettere in campo per essere certi che conoscenza ed esperienza siano diffuse, ma anche che non vi sia un’inondazione?
Lasciatevi trasportare da Mauro nei meandri di Particular Software, per scoprire come una realtà “dispersa” su 17 time zone gestisce collaborazione e condivisione del sapere. Analizzeremo sia i processi, che ci siamo creati, che gli strumenti digitali che usiamo quotidianamente.
Microservices architecture is it the right choice to design long-living syste...Mauro Servienti
Microservices all the thing! they say. Nowadays it seems that if architectures are not microservices based they are not worth the name. Is it really true? Do we really need a (micro)services based architecture?
We should design our systems with longevity, manutenability, and evolution simplicity in mind. Not hype. Long living systems are our primary goal. We'll analyze most common errors and we'll see how architecture can be a game changer in systems design.
Join Mauro in a journey that aims to disclose what it means to build a distributed system based on a (micro)services oriented architecture.
Titles, abstracts, and bio matter... oh my! @ Global Diversity CFP Day 2019Mauro Servienti
Sei uno studente che deve presentare una tesi? Un manager che deve presentare un report ai colleghi? Un esperto che deve presentare i risultati di uno studio ad una conferenza? O semplicemente avresti voglia di parlare al mondo di ciò che ti appassiona ma non sai da dove cominciare?
Living organizations, particular software @ do IT Better ParmaMauro Servienti
Siamo così abituati ad organizzazioni basate sul tradizionale organigramma che diamo per scontato che sia l'unica opzione.
Un approccio differente è possibile?
Quando sono entrato in Particular, era un'organizzazione tradizionale, sebbene distribuita. Avevamo manager e una gerarchia. Un anno dopo la decisione di rivoluzionare tutto. La miglior decisione di sempre. Intraprenderemo un viaggio che ci permetterà di scoprire che un modello organizzativo diverso è possibile, che un processo decisionale dall'alto verso il basso non è l'unica opzione e che possiamo organizzare la vita lavorativa intorno a quella privata in funzione di un ottimo life-work balance.
Welcome to the (state) machine @ Crafted SoftwareMauro Servienti
Stateless all the thing, they say. In the last few years we’ve been brainwashed: design stateless systems, otherwise they cannot scale, they cannot be highly available, and they are hard to maintain and evolve. In a nutshell stateful is bad. However complex software systems need to do collaborative processing, that is stateful by definition. Stateless myth busted! Collaborative domains deal with long business transactions and need to interact with distributed resources. The traditional distributed transactions approach, even if tempting, is a time bomb. This is when Sagas come into play. Sagas allow to model complex collaborative domains without the need for distributed transactions and/or orchestration across multiple resources. Join Mauro on a journey that aims to disclose what sagas are, how they can be used to model a complex collaborative domain, and what role they play when it comes to designing systems with failure and eventual consistency in mind. (It’s all right, I know we’re you’ve been)
PO is dead, long live the PO - Italian Agile Day 2018Mauro Servienti
Cosa succederebbe se i prodotti non fossero gestiti dai manager? O addirittura, cosa se i manager non ci fossero proprio? Chi si prenderebbe la responsabilità di definire la priorità nel backlog? In Particular Software non c’è una struttura gerarchica. La gestione dei prodotti, intesa come vera e propria product ownership, è responsabilità di tutti. Sembra quasi che gli internati siano anche i gestori del manicomio. Non è proprio distante dalla realtà. Oggigiorno sempre più aziende si stanno orientando verso strutture organizzative fluide. Che cosa si può fare per abilitare chiunque a prendere decisioni a qualsiasi livello? C’è un modo per condividere il processo decisionale? Guarderemo come è strutturata Particular Software al fine di abilitare tutto ciò. Analizzeremo come vengono risolti i problemi e quali processi e strumenti utilizziamo per prendere decisioni. Tutto senza infermieri, ooops, senza manager.
Design a UI for your Microservices @ Do IT BetterMauro Servienti
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Microservices and pineapple on pizza what do they have in common - dos and ...Mauro Servienti
Microservices è una delle buzzword del momento. Sembra quasi che un'architettura a microservices sia fondamentale. È veramente così? Faremo un tortuoso viaggio tra le buzzword del momento cercando di districarci tra cosa è bene e cosa è meno bene, ma soprattutto perché. Obiettivo è quello di comprendere quali sono i limiti di certe scelte architetturali e quali gli errori da non commettere. Il tutto nell'ottica di garantire ai nostri sistemi 'lunga vita e prosperità' (cit.)
All our aggregates are wrong (ExploreDDD 2018)Mauro Servienti
It always starts well. At first glance the requirements seem straightforward, and implementation proceeds without hiccups. Then the requirements start to get more complex, and you find yourself in a predicament, introducing technical shortcuts that smell for the sake of delivering the new feature on schedule. In this talk, we'll analyze what appears to be a straightforward e-commerce shopping cart. We'll then go ahead and add a few more use-cases that make it more complex and see how it can negatively impact the overall design. Finally, we'll focus our attention to the business needs of these requirements and see how it can shed light on the correct approach to designing the feature. Walk away with a new understanding on how to take requirements apart to build the right software.
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Cosa succederebbe se i prodotti non fossero gestiti dai manager? O addirittura, cosa se i manager non ci fossero proprio? Chi si prenderebbe la responsabilità di definire la priorità nel backlog? In Particular Software non c’è una struttura gerarchica. La gestione dei prodotti, intesa come vera e propria product ownership, è responsabilità di tutti. Sembra quasi che gli internati siano anche i gestori del manicomio. Non è proprio distante dalla realtà. Oggigiorno sempre più aziende si stanno orientando verso strutture organizzative fluide. Che cosa si può fare per abilitare chiunque a prendere decisioni a qualsiasi livello? C’è un modo per condividere il processo decisionale? Guarderemo come è strutturata Particular Software al fine di abilitare tutto ciò. Analizzeremo come vengono risolti i problemi e quali processi e strumenti utilizziamo per prendere decisioni. Tutto senza infermieri, ooops, senza manager.
Shipping code is not the problem, deciding what to ship it is!Mauro Servienti
This document discusses an organization's approach to prioritizing work and developing software. It emphasizes focusing on solving clear problems rather than executing on estimates or deadlines. Work is organized into buckets or strategies, each with a dedicated squad prioritizing issues. Issues go through an intake process to clearly define the problem before being selected for a cross-functional task force to implement a solution. The goal is for squads to proactively address problems rather than reactively execute work.
GraphQL - Where are you from? Where are you going?Mauro Servienti
GraphQL, inventato da Facebook per risolvere un problema molto specifico, è diventato uno standard. Le applicazioni client lo utilizzano per leggere e manipolare i dati esposti dai server back-end. È così flessibile che recentemente GitHub l'ha adottata per tutte le sue API. Il paradigma è semplice e tuttavia potente tale da consentire la manipolazione flessibile e la loro composizione da molte fonti diverse. Mauro offre in questo intervento un'introduzione a GraphQL, partendo da una breve storia e poi analizzando come GraphQL risolva i tipici problemi in cui i progettisti API e i loro consumer si possono imbattere.
Dall'idea al deploy un lungo viaggio che passa per git flow e semverMauro Servienti
Parliamo tanto di DevOps e ci concentriamo sui tool senza soffermarci a pensare che DevOps è principalmente una metodologia. Lo scopo è rendere l'intera filiera il più fluida e lineare possibile, rimuovendo impedimenti e cercando di prevenire e anticipare problemi.
Possiamo costruire tutto il processo di sviluppo, partendo dai vagiti iniziali del backlog per finire che il deploy fisico in ottica DevOps? Il processo ha impatto sulle scelte tecniche? Pratiche come SemVer e GitFlow hanno invece un impatto sul backlog?
Analizzeremo l'intero processo di sviluppo di Particular Software, dalla gestione del backlog al deploy automatico in produzione, con lo scopo di evidenziare come pratiche che sembrano disconnesse abbiano invece impatto su tutta la filiera.
This document discusses different approaches to designing a user interface for a microservices architecture. It begins by proposing a domain model decomposition with individual services owning pieces of product data. However, this poses issues for users who need an aggregated view. An alternative presented is to have individual services cache normalized data and compose a view model at the edge. Later approaches incorporate client-side messaging, hosting the composition engine in MVC, and using view components to give services more ownership over vertical slices of the UI. The key takeaways are that the UI structure can be defined at the edge while still keeping domain responsibilities clear across services.
The road to a Service Oriented Architecture is paved with messagesMauro Servienti
One of the options on the table when implementing a Service Oriented Architecture (SOA), or the communication style across multiple microservices, is based on messages and a service bus. This talk will drive you through the basic SOA building blocks, introduce message based architectures, and will connect the dots between technology and architectural principles through some samples using NServiceBus.
4. Mumble...mumble... (upfront)
• È difficile? parecchio... :-)
• Siamo troppo abituati al «coupling» tra componenti visuali e logica
• Quindi...il gioco vale la candela?
• Tutta la vita, in particolare al crescere dall’applicazione:
• Sia verticalmente: complessità;
• Sia orizzontalmente: versioning nel tempo;
• C’è rischio di addiction? «Purtroppo» si :-)
• Una volta che ci avete preso la mano scrivereste anche il notepad
con M-V-VM;
5. Why?... pecccchè?
• Perchè adottare un pattern per la presentazione dei dati?
• SoC e SPoR sono sicuramente due buonissimi motivi:
• Diamo un boost alla manutenibilità liberandoci dello spaghetti code;
• Cerchiamo di separare nettamente le figure coinvolte:
• Il designer non è il developer e il devloper non è il designer;
• Non necessariamente sono figure fisicamente diverse, ma
sicuramente sono momenti diversi;
• Introduciamo la possibilità di testare il comportamento
della logica che gestisce la UI;
6. Talebani o Libertini?
• Dogma: Un pattern è un pattern quindi va sempre
adattato al contesto in cui viene calato;
• Model View ViewModel però...:
• Nella sua implementazione con Wpf/Sl è giovane;
• Molte cose sono decisamente borderline;
• Il contesto d’uso classico, un rich client, lo rende complesso da
applicare perchè le celte da fare sono moltissime:
• MVC con Asp.net ha decisamente poca libertà di manovra per come è
fatto http;
• MVP con WinForms è molto limitato dalle limitazioni di WinForms;
• All’inizio essere un po’ talebani aiuta a pensare;
9. Overview
DependencyObject POCO Instance
Tipicamente la UI I nostri dati
Dependency CLR
Binding Expression
Property Property
• La BindingSource può essere una qualsiasi
istanza, senza nessun requisito;
• Il BindingTarget deve essere una Dependency
Property, e quindi un l'istanza di un Dependency
Object;
10. DataFlow Direction
DependencyObject POCO Instance
Dependency CLR
- OneWay
Property Property
- TwoWay
- OneWayToSource
• OneWay: il binding è monodirezionale:
• da Source verso Target;
• è il default per controlli i read-only (eg. TextBlock);
• TwoWay: il binding è bidirezionale:
• I dati viaggiano da Source verso Target e viceversa;
• È il default per tutti controlli r/w (eg. TextBox)
• OneTime: il binding viene valuato una sola valta:
• da Source verso Target;
11. Data «Triggers»
• Cosa causa il pull/push dei dati?
• Source (data) Target (UI):
• OneWay e TwoWay: la source deve implementare un motore di notifica
come ad esempio INotifyPropertyChanged;
• Nel caso di collection la collection deve supportare la notifica delle
variazioni interne... More to come;
• Target (UI) Source (data):
• TwoWay e OneWayToSource:
• «Default»: predefinito, la source viene aggiornata nel momento in cui il
controllo corrente perde il focus;
• «PropertyChanged»: la Source è aggiornata ad ogni variazione della
proprietà del target;
• «Explicit»: la source viene aggiornata solo su richiesta esplicita:
BindingExpression.UpdateSource();
13. Da WinForms a *.DataContext
• In Windows Forms era responsabilità di ogni singolo
controllo esporre un sistema per il data binding:
• .DataSource;
• .SetDataBinding(...);
• TextBox.????;
• FrameworkElement espone DataContext:
• Razionalizza e uniforma l'approccio;
• È una Dependency Property:
• beneficia del concetto di ereditarietà del valore;
• Supporta a sua volta data binding;
14. Binding Pipeline
TextBlock MyObject
Source Target
Text DateTime
Property Target Source Property
• Per impostazione predefinita il motore di binding per
la conversione chiama ToString()
• NB: In assenza di un template;
• Possiamo intervenire nel processo di conversione
scrivendo un ValueConverter
15. Binding Pipeline: IValueConverter
• IValueConverter definisce solo 2 metodi:
• Convert( ... ): viene invocato dal processo di binding nel momento
in cui il dato si muove dalla Source verso il Target;
• ConvertBack( ... ): viene invocato durante il passaggio
opposto, mentre il dato viaggia dal Target verso la Source;
<TextBlock Text="{Binding
Path=PropName,
Converter={StaticResource myConverter}}" />
17. Separation of Concern
• Il concetto di command in Silverlight/Wpf è basato sul
command pattern:
• La logica di esecuzione è independente dalla UI;
• Incapsulare la logica di esecuzione permette di avere più entry-
point verso quel comando
• Chi si ricorda le Action di delphi...?
18. L'interfaccia ICommand
• CanExecute( Object ):
• L'invoker può sapere se il comando può essere eseguito in un
determinato contesto;
• Execute( Object ):
• L'invoker può invocare il comando;
• CanExecuteChanged event:
• Il comando può notificare l'invoker di eventuali variazioni del suo
stato;
20. Please welcome M-V-VM
presentation
View
DataBinding
Command
engine
Il centro del ViewModel D.I.
mondo!
Repository<T>
Model
data
Adapter
Somewhere in
time...
22. Actors: Model
• È uno ed uno solo:
• Rappresenta i dati, che in quanti tali, vanno sempre protetti;
• Può essere un Object Model o un Domain Model:
• È molto più facile che sia un «Object Model» condito da servizi;
• È responsabile della validazione statica:
• Le regole di validazione non pertinenti al caso d’uso;
• È totalmente ignaro del mondo in cui è inserito:
• Non implementa INotifyPropertyChanged;
23. Actors: ViewModel
• Rappresenta un caso d’uso del Modello:
• È un aggregatore di logica e dati;
• È responsabile della validazione contestuale:
• Casi d’uso diversi con regole di validazione diverse per dati uguali;
• È conscio di essere in un mondo basato su DataBinding:
• Implementa INotifyPropertyChanged, ma non deriva da Dep.Obj;
• E’ responsabile del «flattening» del grafo:
• Ricuce l’uso dei comodi ma scomodi converter;
24. Actors: View
• È «stupidamente» legata al ViewModel:
• Non prende la benchè minima decisione;
• Deve essere a prova di designer:
• Quindi non deve aver nessun rapporto con il codice;
• Deve poter essere disegnata:
• Focus on the «Blendability»;
25. Who comes first?
• Abbiamo un duopolio...
• ma...chi comanda?
• ViewModel first?
• View first?
• Io sono per il ViewModel first perchè vedo la View come
una passive-view;
27. Recap
• Abbiamo definito il modello: Person/Address;
• OT: Abbiamo introdotto il concetto di DataContext;
• Abbiamo costruito dei casi d’uso sul modello: ViewModel
• Visualizzare un elenco di persone;
• Visualizzare il dettaglio della persona selezionata;
• Abbiamo «visualizzato» i casi d’uso: View;
• Potevamo scrivere dei test prima di arrivare alla View?
• Servono ancora gli «U.A.T.»?