I’ve applications that can work in two distinct configuration, they are based on WPF and MVVM, where the VM communicates with the Domain / Business Logic through services like IXxxxService. All View Models depends from one or more services and thanks to Castle I can decide with configuration file which concrete class to use for [...]
Continue reading about Managing remote logging with Log4net and WCF
Some days ago I blogged about an implementation of persistent cache component based on Managed Esent and PersistentDictionary. This component is injected into other components thanks to Inversion of Control and it is a Singleton object. Being a singleton is a requisite because it permits to different dependent objects to share the same cache, moreover [...]
Previous Parts of the series Part 1 – The basic of interception Part 2 – Selecting Methods to intercept Part 3 – The first interceptor AOP works great if you have clear interfaces where you want to put some standard and shared logic, and a Service Oriented Application falls in this category. A service is [...]
Continue reading about AoP with castle part 4–Adding AoP to service oriented App
I use AutoMockingContainer extensively in my test projects, and I ‘ve build over time an automocking container that satisfy all of my needs. Thanks to Castle Windsor, using complex logic with the AutomockingContainer is a breeze. Suppose you have this ViewModel Figure 1: ViewModel under test The only aspect I’m interested in is the SelectedLinkResult [...]
Continue reading about Castle and Automock, avoid resolving properties
I know, service locator is an antipattern, but sometimes, when you begin to refactor existing code written with no IoC in mind, service locator can help you a little bit in restructuring your code. A service locator pattern work this way: you have some static or gloablly avaliable class named: ServiceLocator or IoC, and every [...]
Continue reading about Mock, Service Locator, Automocking container and the hard life of testers