Archives

Archives / 2008 / August
  • Played around with Microsoft Extensibility Framework - MEF

    I played around with the June CTP of the Microsoft Extensibility Framework (MEF). I wanted to try both Dependency Injection (DI) and adding classes during runtime to extend an application with more logic without shutting down the main app. As an example I created a LogManager, I thought of the most simple possible thing to do. The LogManager will use different kind of loggers, to log exceptions. During runtime I wanted to add more loggers. For example lets pretend we are building an app where we log all exceptions into a database, suddenly we need to log it into a XML file also. If we don't use a provider based solution, we would probably open our application, add the new code to log into an XML file, recompile and deploy. But what with the MEF we can add the extra logger without recompiling the app, we don't even need to shut it down. (Well, this nothing new, this have bean possible for ages with framework like Spring).

    I will start writing about my Loggers before I go into the LogManager and how to add "components" to the MEF frameworks containers. Here is a common interfaced used by the Loggers:

  • Map Objects to one Object

    In my previous post I wrote about how we could use Dynamic Compilation for mapping object to object in a configuration file, mosly for fun to simply try something different. I spend a few minutes to see if I could do something more with it. It ended up that I can use it to several things, like creating Factories, or send in different kind of objects and map several into one. Here is how I for example can send in more domain object to map them into a PresentationCustomer:

  • How to map a Domain model to a Presentation Model, can this be something?

    If you have read my previous post about Presentation Model, I decided to try to see if I could make the mapping between the Presentation Model and the Domain Model simple by creating an Object to Object Mapper. I don’t want to use a messy XML file or attributes on the classes to handle the configuration of how object should be mapped to each other. Instead I wanted to use the nice Object Initializer feature in C# 3.0 which I think is easy to read and easy to use. Here is a modified version of my Mapping method I had in my CustomersController class in my previous post:

  • Who's to blame, Microsoft and/or the .Net Community

    I’m interested in why most of Microsoft and some other developer’s demons about writing apps mostly begin with the creation of a database? The design of the app will more or less in that case be driven by the database schema, after the database in place the Data Access Layer will be built and the entities will mostly reflecting the database schema. A data base like Microsoft SQL Server is a relation database, so our model will more or less be a relational model instead of a more object oriented model. That can make it harder to use good design patterns and principles to solve some Implementation problems. OO has a rich toolset for modeling the domain than the relation model.