Tamir Khason
http://khason.net
Feb’ 09
Sponsored by:

This is not a lesson
You should attend

What is “good application”?

Architecture…

… but what
about me?
This is Nick
… and Nick has
also a lot of letters
for this machine

Smart Client Application should be
Simple
Useful
Deployable
Maintainable
Extensible
ACCEPTABLE

What is “Smart Client”?
My presentation July 2002 My presentation Feb’ 2009
 WinForms User Interface  Client User Interface
 Deployed via central server  Zero footprint deployment
 Uses local resources  Users local resource
 Uses server based data and  Synchronizes and distributes
processing data and processes
 Works better connected  Smart sensitive to local
 Works offline environment
 Minimum dependencies

The Process

Planning
Focus on FEATURES Focus on SCENARIOS
 Stability  Excitement
 Incremental  Breakthroughs
improvement  Most probably will
 Most probably “End- leave existing
to-End” scenarios will customers behind
not work

Architectural review
But it
cumbersome We need
componentization
There is a ton of
dependencies

Dependencies management
 Types in a same component can depend one on each other
 Cross-component dependencies must be controlled
 Can be depend on component in lower layer
 Must not be hard depend on component in higher layer
 Must avoid to be soft depend on component in higher layer
 Need someone else to manage dependencies on the same
layer
 Less dependencies – better!
 Also less assemblies – better!
 … in general – less is better – simpler is better!

10 Design dogmas
Component oriented Primitive Oriented
 Rich APIs with lots of  No external dependencies
features – ton of  Great evolvability, often
dependencies very poor usability
 Great usability, poor  Incoherent type discovery,
evolvability but not required reflection
 Easy type discovery, but  Good for low level stable
need reflection framework
 Good for higher level
components - not for the
core

Extensibility Framework?
 There is no “Official” extensibility framework, so you
can…
 Create from scratch
 Buy/use something good…
 Wait for .NET 4.0
 Use MEF - Managed Extensibility Framework + WPF today
Catalog
Value Resolver
Composition container
Part Part Part
Export Import Export Import Export Import

How it works?
Who has service
I need?
I have!
[Import]
public IEnumerable<IYourService>
YourServices { get; set; }
[Export(typeof(IYourService)]
public class SomeService : IYourService

Who is who and what can it do?
 Parts relate through contracts
 Imports are contracts parts need
 Exports are contracts parts offer
 The Container is matchmaker
 It queues catalogs
 Parts can load lazily
 Parts can have different lifetimes
 Parts are extensible and reusable

Contracts
 Preconditions, rather then endless try-catch blocks
 Postconditions, rather then endless if-else blocks
Assumption.SetPolicy(AssumptionPolicy.Break, new AssumptionHelper());
…
public NotNullSet(HashSet<T> set) Assumption.NotNull(set);
…
Assumption.IsTrue(typeof(T1) != typeof(T2), \"The two types of values in a mapping cannot be the
same type.\");
 The best about this is Static Analysis!

But what’s with “Compatibility”?
 Cross-Version Compatibility
 Cross-Redistribution Compatibility
 Backward Compatibility
 Forward Compatibility
 Binary Compatibility
 Source Compatibility
 API Compatibility

Primitives and extensibility?
 APIs are published as interfaces into a
“programmability” assembly
 Embed interfaces at compile time
 Can be deployed to any version of the managed
application
 We can “cast” one interface into other in runtime
– loose type coupling
 We can add some aspects and logic in compile
time with custom compilers
 In .NET 4.0 only!
 By now – you can use PostSharp

Generic co- and contravariance
 It’s scary, but simple
 We can cast to ancestor types
private void WriteSomething(object[] something) { }
…
var something = new string[] { \"It's something\" };
WriteSomething(something);
 But it not always works
private void WriteSomething(IEnumerable<object> something) { }
…
var something = new List<string> { \"It's something\" };
WriteSomething(something); // Compiler says “NO”!
 So should we be able to pass Ixxx<TDerived> for
Ixxx<TBase>?

Generic co- and contravariance
 If T is an output → IX<TDerived> for IX<T>
 It’s covariance
 …and can be used as IX<out T>
 If T is an input → IX<TBase> for IX<T>
 It’s contravariance
 …and can be used as IX <in T>
private void DoSomething(Func<object, IValueConverter> something) {
this.Converter = something(this.Whatever); // Oh, NOT!!!
}
…
var something = new Func<string, IValueConverter> { };
DoSomething(something);

AOP – WTF?
 You have INotifyPropertyChanged primitive
public class MyPrimitive : INotifyPropertyChanged {
public event PropertyChangedEventHandler PropertyChanged;
protected virtual void OnPropertyChanged(string name) {
if (PropertyChanged != null) PropertyChanged(this, new PropertyChangedEventArgs(name));
 For each setter of each descendant you need to call
virtual method OnPropertyChanged
public class MyClass : MyPrimitive {
private int _myProperty;
public int MyProperty { get { return _myProperty; }
set { if (_myProperty != value) { _myProperty = value;
OnPropertyChanged(\"MyProperty\");
 Rather then use automatic setters
public int MyProperty { get; set; }

AOP – WTF?
 The best is to create your own compilation rule…
 … or even some dynamic primitives…
 … but it only possible in .NET 4.0
 Meanwhile, you can use PostSharp and
OnMethodBoundaryAspect primitive to tell compiler
what to do
internal class SetterWrapper : OnMethodBoundaryAspect {
public override void OnEntry(MethodExecutionEventArgs eventArgs) {
var myPrimitive = eventArgs.Instance as MyPrimitive ;
_propertyInfo = myPrimitive.Class.GetProperty(_propertyName);
eventArgs.MethodExecutionTag = myPrimitive.OnBeforePropertyChange(_propertyInfo, newValue,
oldValue);
eventArgs.FlowBehavior = FlowBehavior.Return;
 All the rest will be done automagically

Side by Side
 .NET 1.x and 2.x CLR - Side by Side on the same
machine
 Good for programs
 Bad for add-ins
 Breaks on 3.x “red bits”
 .NET 4.x CLR – Side by Side in process with 2.x CLR
 Each module runs again its expected version of CLR
 Can be done today by some unmanaged injections

The Concept

Real life software Perform
Specialised tasks
Can process
more than one
request at a time
Increase staff
during peek
hours or replace
staff on trouble

Real life software
Async Process
Queues
Storages
Dispatcher Processor Worker

Need a change of thinking
 To throw out
 Local states
 Client locks, transactions and scopes
 Fault tolerance
 To bring aboard
 Asynchronous operations
 Simplicity
 Self descriptive behaviors and
components

Local resources?
 Windows Sensor and Location platform
 Basically the better way to access well-known device types
 Build context aware applications
 Can be used today by wrapping HID_* methods
 Microsoft Sync Framework
 You can synchronize your application or device and provide
it offline capabilities
 Build “sometimes connected” applications
 “DirectHardware” is your friend and savior
 DirectX helps you to leverage client’s hardware
 It also can varnish a bit your app

WPF – Huh?

Architecture (should)= Simplicity

Are you familiar
with WPF?

We already have a lot of stuff
 We have trees in WPF
 Logical tree – is what you put in XAML
 Visual tree – the what WPF renders for us
 Inheritance – frozen hybrid of two above
 We have Context
 All Data Context inherited via trees
 Resources inherited via Logical tree
 Routed events and commands can be used
through Visual tree
 Data Templates = Views

2 conclude
 Think as consumer, not as developer
 DO design APIs by using it (writing code)
 Keep It Simple, Stupid!
 Set goals, gates and make an order
Staging Feature
branch branch
Staging
Main Feature
branch
branch
Staging
branch
 Avoid integrating unfinished features (yes, even if it is
very cool feature)

2 Read
 My Blog
http://khason.net
 Windows Client Development
http://windowsclient.net
 Windows Presentation Foundation (Toolkit, Futures,
Ribbon, Labs, M-V-VM)
http://codeplex.com/wpf
 Managed Extensibility Framework (MEF)
http://codeplex.com/mef
 PostSharp + Aspect-Oriented Programming.NET
http://postsharp.org
 Microsoft WHDC site (Sensors)
http://microsoft.com/whdc/sensors
 Microsoft Sync Framework
http://msdn.microsoft.com/en-us/sync

Thank you
Questions?
… and I do not need “Potential – Passion” slide anymore…
tamir@khason.biz
http://khason.net