Skip to main content

Posts

Showing posts from June, 2022

Clean app startup (WPF)

Simple easy to read code is the building blocks for complex applications, and to this end, the is how I now start all desktop apps (written in XAML / WPF). This is nothing new (and not original) but it's been refined & destilled down to a point of simpliclity :) Single line written once and forgotten about... Need to add Exception handling - write it in a Module... Need to add Heartbeat monitoring - write it in a Module... Using DI - do it in a Module... Startup XAML - guess what, done in a Module... Want only one instance of the app - do it in a Module... So lifting from my updated Simple.Wpf.Template on gitHub , I have the following set of Modules defined - this forms the basis for all apps I'm asked to develop for clients: The complexity is hidden away in the ModuleLoader class, simple put this scans & loads any type with the ModuleConfigurationAttribute, orders the Modules according to the properties of the Attribute and dynamically invokes the Modules. Check out th

Benchmarking DateTime.ToString("...")

Looking to eek-out as much perf as I can from some code (C#) at work, and looking at all the .ToString() manipulations in the code and I came across the following: How can I quickly workout if I want to do something around this? BenchmarkDotNet to the rescue, and this library really does make benchmarking easy (and fun!). I created an overload of the extension method which internally uses a cache to avoid the repeative ToString() calls: Only small issue was wanting to test a Static methods, and this only involved creating a wrapper class with annotated methods(calling the static implementations), also preloaded the internal cache: Results below, make-of-it what you will...

Rx EventAggregator<T> for desktop apps

In my continuing (point-less) mission to avoid using anything related to MS Prism - a quick implementation of an EventAggregator using Rx - took about 5 minutes to write for a problem I currently have, normally try and avoid using such a pattern as it can lead the scattering of business logic which can hard to 'follow' when refactoring / re-visting code. Trying to kepp the interace as simple and obvious as possible (symetric design) - this will be injected by the container: Simple base event class, not thing special at the moment, might add a timestamp in the future, but more likely to do that with Rx on the event stream using the apply named Timestamp method: Included a simplifed Schedulers wrapper - idea being you can get any of the Rx Schedulers in one place, and importantly makes unit testing easier: Show me the money...