Smart Client Development

5,133 views

Published on

Those days, when it seemed, that web applications have overthrown standard “cumbersome” client apps, we’ll speak about present and future of consumer oriented desktop applications. This includes, but not restricted to patterns of LOB applications development with WPF, right multimedia support of DirectX bridge and new features, waiting for you in Windows 7. Also we’ll speak about subject oriented programming, will be introduced in NET. 4.0 and how to leverage it even today with the current version of Microsoft framework. tits will be shown during the session, thus restricted to mature audiences

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,133
On SlideShare
0
From Embeds
0
Number of Embeds
2,155
Actions
Shares
0
Downloads
147
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Smart Client Development

  1. 1. Tamir Khason http://khason.net Feb’ 09 Sponsored by:
  2. 2. This is not a lesson You should attend
  3. 3. What is “good application”?
  4. 4. Architecture…
  5. 5. … but what about me? This is Nick … and Nick has also a lot of letters for this machine
  6. 6. Smart Client Application should be Simple Useful Deployable Maintainable Extensible ACCEPTABLE
  7. 7. 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
  8. 8. The Process
  9. 9. 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
  10. 10. Architectural review But it cumbersome We need componentization There is a ton of dependencies
  11. 11. 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!
  12. 12. 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
  13. 13. 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
  14. 14. How it works? Who has service I need? I have! [Import] public IEnumerable<IYourService> YourServices { get; set; } [Export(typeof(IYourService)] public class SomeService : IYourService
  15. 15. 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
  16. 16. 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), quot;The two types of values in a mapping cannot be the same type.quot;);  The best about this is Static Analysis!
  17. 17. But what’s with “Compatibility”?  Cross-Version Compatibility  Cross-Redistribution Compatibility  Backward Compatibility  Forward Compatibility  Binary Compatibility  Source Compatibility  API Compatibility
  18. 18. 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
  19. 19. Generic co- and contravariance  It’s scary, but simple  We can cast to ancestor types private void WriteSomething(object[] something) { } … var something = new string[] { quot;It's somethingquot; }; WriteSomething(something);  But it not always works private void WriteSomething(IEnumerable<object> something) { } … var something = new List<string> { quot;It's somethingquot; }; WriteSomething(something); // Compiler says “NO”!  So should we be able to pass Ixxx<TDerived> for Ixxx<TBase>?
  20. 20. 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);
  21. 21. 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(quot;MyPropertyquot;);  Rather then use automatic setters public int MyProperty { get; set; }
  22. 22. 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
  23. 23. 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
  24. 24. The Concept
  25. 25. 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
  26. 26. Real life software Async Process Queues Storages Dispatcher Processor Worker
  27. 27. 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
  28. 28. 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
  29. 29. WPF – Huh?
  30. 30. Architecture (should)= Simplicity
  31. 31. Are you familiar with WPF?
  32. 32. 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
  33. 33. 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)
  34. 34. 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
  35. 35. Thank you Questions? … and I do not need “Potential – Passion” slide anymore… tamir@khason.biz http://khason.net

×