SILVERLIGHT 2 . 0a starting point forLine of Business

Application

Two words about meGiorgetti Alessandro

•Electronic Engineering Degree (Microelectionic specialization)

•Cofounder of DotNetMarche and member of Ugi.Net

•Founder or SID s.r.l.

•Links:• DotNetMarche – www.dotnetmarche.org

• Blog – www.nablasoft.com/guardian/

.

Index•Introduction•Engineering of a Solution: defines the objectives and achievements•Define the Architecture (Structura: WPF/SL application framework).•Guidelines: states some standards for the development phase •Implementation (‘Structura’ a Silverlight/WPF Application Framework, alpha version)

Introduction•Silverlight is a framework and a set of technologies for the realization of RIA applications and small games.

•Silverlight is a client side technology, so we have a series of limitations in accessing various library functions to avoid that the browsers of our application can be turned into ‘informatical assault machines’.

•Silverlight heavily relies on an asynchronous programming model to avoid blocking the user interface and providing a better experience to the user.

Introduction- Features2D GraphicsAudio/VideoAnimationsLayout controlsControls(wpf subset)Styles/TemplatesDatabindingNetworking (http/sockets).NETLinq

XML ApiHTML integrationLocal StorageAddictional Controls (Silverlight Toolkit)

Introduction -Tools• Silverlight Runtime.• Silverlight SDK.• Visual Studio (2005/2008).• Visual Studio tools updates for Silverlight

• Web and Silverlight projects.• Limited Application Designer (non interactive design

surface).• Microsoft Expression Suite (Blend)

www.silverlight.net

Engineering of a Solution

•Identify the target of the Application(s): define the type of the end users, the achivements application has to make, etc…•Define the features.•Setup a ‘requirement analysys’ team.•Write down some features and specifications (…)•Setup a ‘development team’.•…

There’s a lot of work to do before writing any code, do not underestimate it at start!

Engineering of a Solution

BUT, in this presentation we take most of those step for granted.

The Demo App will be a starting point for building an Invoice Manager System.

We use this as a test to build our OWN APPLICATION FRAMEWORK.

Architecture GoalsSL/WPF Application Framework :maximize code reuse, it can be used as the base to build many different types of applications.

Pluggable and Modular Application (Loose Coupling whenever possible):Adds great extensibility, you can develop the application in small parts and deliver each module when ready. Also it’s easier to replace an old module with a new one.This approach has to be used inside a module too.

Hot Swap : It mostly depends on how you develop your module, keep the coupling low and develop a good infrastructure for exchanging data between modules.

Architecture GoalsMultitarget Application – WPF/Silverlight: you gain advantage from different aspects of those infrastructure, but you also have to face different problems.Silverlight – pro:•grants an easier deployiment experience•you can reach a wider range of users•updates are delivered on the fly•Low level system requirements (a browser and a connection)Silverlight – Contro:•Interaction with datasources through webservices•Totally Async programming model•Contain the size of the application to reduce download times.•Strict security model

Architecture GoalsWPF - pro:•Richer experience and powerful controls for your UI.•Total control on your application•Sync and Async programming model•Several way to access datasourcesWPF – Contro:•Higher system requirements •A Deployment project is needed•Updates delivered through service packs or patches

ArchitectureWe have to face many and different challenges:•Build different kind of applications (WPF/SL).•Build a pluggable system.•Separate the business/application logic from the UI.•Build different kind of UI (patterns and code reuse).•Different ways to access Data.•Deployment.

Each Area has its own problems, so it’s better to face them individually (but having however a picture of the whole system to keep an eye on the interactions).

Silverlight and WPFTypical Silverlight application:

Silverlight App

Website(Asp.net + SL) Web Services

Local

Remote

3° party

Silverlight and WPFTypical WPF application:

Client/UI module Web Services

Local

Remote

3° partyDirect Access to reachable data

sources

Architecture Choice 1Loose Coupling always

winsGiven the different modules involved you see it easily:define interfaces for modules whenever possible, it’s more code you write at start, but in the long run it always pays.•Forces you to think and plan carefully.•You can develop the application as a set of BlackBoxes.•You can isolate major implementation challenges and face them one by one.•Simplifies tests.•The flexibility it adds to your application is invaluable.In the end: Interface Interface Interface!

Architecture Choice 2Try to define a uniform way to access the data sources and the business services.Implement them as webservices can be good for both the environment because:1- it’s the only viable choice for Silverlight.2- simplifies the porting from Silverlight to WPF.2- they can be replaced easily in a WPF application without having to distribute them to the client installations.3- a webservice adds a shield layer to the real implementation.4- you should not access the webservice directly but define an interface that the application will use to access it, so you can also change the service completely without affecting the rest of the application.

Architecture Hint

Avoid to reinvent the wheel!

An high level application framework can be build upon and/or use a set of pre existents frameworks.

With this in mind, before writing any line of code, give a look around and see if there exists something that can help you solve your problems in advance and develop your code faster and safer.

Architecture Choice 3Pluggability through Inversion Of Control

IoC: is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to the traditional architecture of software libraries.Instead of specifying a sequence of decisions and procedures to occur during the lifetime of a process, the user of an IoC framework writes the desired responses linked to particular events or data requests.Inversion of Control is a style of software construction where reusable, generic code controls the execution of problem-specific code, with the strong connotation that the reusable code and the problem-specific code are developed independently and the result often being a single integrated application.

Architecture Choice 3Pluggability through Inversion Of Control

So the basic idea is:

With a large numbers of interfaces and implementations we need an infrastructure to handle them. That's what a "lightweight IoC container" do.

Master IChild

Child

Architecture Choice 3Pluggability through Inversion Of Control

When properly configured they are able to create objects and configure them through "Dependency Injection"

The basic idea of the Dependency Injection is to have a separate object, an assembler, that populates a field in the "master" class with an appropriate implementation for the "child" interface.

There are three main styles of dependency injection: •Constructor Injection•Setter Injection•Interface Injection.

Architecture Choice 3Pluggability through Inversion Of Control

Each module and/submodule should be represented by Interfaces:•It grants the operativity•It shields the implementation

We can take advantage of an IoC system to inject dependencies into modules (configuring them) or to invoke the creation and execution of application classes that obey to specific interfaces.

Architecture Choice 3Pluggability through Inversion Of Control

The application bootstrapper will have a way to retrieve the configuration for each module (the mappings) and to register them in the IoC system.

Each high level module will obey to a set of interfaces common to the entire applciation and that the bootstrapper knows how to use to start the execution of a module.

Architecture Choice 3Pluggability through Inversion Of Control

The IoC system itself will be hided behind an interface:•You can change the IoC engine without impact for the application•Each runtime (SL/WPF/etc…) has its own IoCs•You can extend the IoC with features you may need.

SL Architecture Requirement

The SIZE of a Silverlight application DOES matter!

Building a monolitic application isn’t really good, you will force the user to download it as a whole, even the pieces that he will never use.

So you have to fraction you application in submodules and deliver them to the user when he requests for those functionalities (Deferred Downloading).

The application framework should be able to do it.

Communication between modules.

Different solutions can be implemented to let the modules communicate maintaning the loose coupling:•Shared Entities Assemblies.•Define a set of communication classes to be used/registered as singleton in the IoC (ex: application settings classes).•The IoC system can be used as a repository of informations (not only of types).•Event Brokering (with the classic publisher/subscriber pattern)•Etc…

Structura

a Silverlight/WPF application framework

alpha verion

WPF application schema

Framework

Business Entities & DTOsData Access Facilities:ORM, Direct SQL, etc..

WPF Extended Controls

IOC, Deferred Downloading, Security & Permissions ServicesMVC/MVP/MVVM/etc…Event BrokeringUtilities & Helpers

Application Infrastructure(Operational Interfaces, Modules

Communication and Messages system, etc…)

Appl

icati

on M

anag

er(B

oots

trap

, Mod

ule

Com

mun

icati

on)

Auth

entic

ation

& A

utho

rizati

on S

ervi

ces

Logg

ing

Syst

em

Uni

t Tes

ts

Data Access & Data Manipulation Layer

Service Layer (WCF, Web Services, etc…)

Application Module 1

Application Module N

WPF Extensions & Custom Controls Specific for the application

Application Services

SiL app. Schema (client side)

Framework

Business Entities & DTOsSilverlight Extended Controls:Windows, Menu, etc…

IOC, Deferred Downloading, Security & Permissions ServicesMVC/MVP/MVVM/etc…Event BrokeringUtilities & Helpers

Application Infrastructure(Operational Interfaces, Modules

Communication and Messages system, etc…)

Appl

icati

on M

anag

er(B

oots

trap

, Mod

ule

Com

mun

icati

on)

Auth

entic

ation

& A

utho

rizati

on S

ervi

ce L

ayer

Logg

ing

Syst

em

Uni

t Tes

ts

Service Layer (WCF, Web Services, etc…)

Application Module 1

Application Module N

Silverlight Extensions & Custom Controls

SiL app. Schema (Server side)

Framework

Data Access Facilities:ORM, Direct SQL, etc..

DDD + Patterns:IOC, Security & Permissions ServicesUtilities & Helpers

Auth

entic

ation

& A

utho

rizati

on S

ervi

ces

Logg

ing

Syst

em

Uni

t Tes

ts

Data Access & Data Manipulation Layer

Service Layer (WCF, Web Services, etc…)

Business Entities & DTOs

Application Services

We must implement anything related to Data Access as a server side solutionas well anything that performs complicated or very long elaborations (to keep high the responsiveness of the application, remember we do not have blocking calls in Silverlight)

What we will see1. How the application framework is structured2. How to realize a generic HOST for application modules3. How to build your entity classes & DTOs to use them in

bindings in an effective way4. How to implement an MVP/MVVM pattern for writing

any application form5. How to build a shielding layer for the Data Access

infrastructure (web services or direct access to DBs)6. How to take advantage of the IOC module to reduce the

size of any single application module (ie: place the interface of the DAL in the infrastructure assembly and the real implementation in another and register it in the IOC)