Its been awhile since I put up a blog post and that’s partly due to being so busy working on my two Windows Phone 7 Apps. Which brings me to the topic of this post and one which I think is important for fellow devs to understand. I am one of the lucky few that have received a real device and its very nice! :) (thanks Microsoft!)
One of the first things I started to do was performance test my App on the device and found that the device is a lot slower than the emulator. So I started to run some optimizations and wrote a small benchmark App to help me work out which refactorings were the fastest. I was rather pleased with myself when I ended up getting improvements of 200 and 300%! in the emulator. Then thought I’d see how much of that new gain transferred to the device. The results shocked the hell out me, as rather than getting a gain I ended up with a lost of 50%! That’s right my optimizations did the exact opposite of what they were supposed to do.More...
I’ve just released an update to the UnitTestEx component which as the following additions:
- Re-factored API signatures to make them much simpler
- ExecuteUnitTestScript to support in/out params
- Renamed ExecuteUnitTestValidationScriptReader to ExecuteUnitTestScriptReader which also now supports in params
- Added unit test for all database related features ie ExecuteUnitTestScript
- Added database scripts to allow testing of the new unit tests.
- Compare now supports the ability to treat empty collections as the same as null collections. This feature can be useful if de-serialize your expected results from an XML file and your actual forces some collections to be null but the default behaviour of the code is to have initialized collections.
For anyone who has been using an older version, this version represents a number of breaking changes. The changes however are not significant and the APIs are now quite stable.
If you haven’t checked out the component yet, take a look at the original post and the code on CodePlex.
In an effort to start getting more of the code I’ve been working on out in the public domain, I’ve finally released all the code for the dnp.Framework on CodePlex. While its not all complete, most of the code is quite stable and can be used now!
Some of the major components that are included in the framework include:
- Database Explorer API: An object oriented database schema API which is ideal for anyone wanting to do code generation. Its based on the provider pattern, so while it currently only supports SQL Server 2005+ its fairly easy to create a new provider for any system. This is stable enough for production use and has an extensive set of unit tests.
- Data Provider: This is a database agnostic API which is fairly similar to the one in the enterprise library except it doesn’t support datasets and the like. Its also has little overhead. This was designed before the Enterprise Library had a decent model, and it has also been used on mobile devices with the compact framework.
- DomainModeller: An abstract domain model view of a database schema (extends Database Explorer API). This API is most useful to creating scripts for code generation, where you can concentrate on domain concepts such as base classes, derived classes, namespaces and relationships etc, rather than database concepts. Using this API for code generation can significantly reduce the amount of code typically required.
- ServiceModel: This project is still under development, but aims to provide the first ‘Model’ that extends the Domain Modeller to define a Service based Application framework. The ServiceModel acts as the abstract API for the final code generation scripts which are currently written using CodeSmith. The scripts currently have good support for the data access layer (repository), service layer (business logic) and entities (using design discussed here). More...
Its been some time since my last post, so I thought I’d start back with news of a small Unit Testing library I’ve been using with my current client. I developed the library to solve a number of issues I was facing while doing my unit tests. The focus of the library is to provide support for:
- Test Spy Pattern: a type of of fake that monitors calls and data passed rather than trying to mock the implementation. A discussion of the pattern can be found in the xUnit Patterns book.
- Comparing entities: the amount of code generally required to test that an entities properties match those of the expected version can be large and tedious to write.
- Data access testing: while using Fakes and the like is great, you still need to test the code that actually talks to the database. This usually ends up taking a reasonable amount of code to setup and execute, making the test harder to read.
This library provides solutions to the above problems which in my experience has produced cleaner tests that are easier to read and understand. The library comes with a fairly detailed User Guide so I wont go into the details of how everything works here, however I will provide a quick overview of how the library attempts to solve these issues.More...
This is the second part of the series which discusses the issues around modeling M:1 (many-to-one) relationships. If you've not read the first part, then its advisable that you read that first before continuing with this part. To keep up to date with this and other blog's you might consider registering with the RSS feed.
Part I: The Problem
Part III: BusinessKey as a value type
Having covered the issues with M:1 relationships and the three different types I'll now present a potential solution which provides the necessary foreign key information, but in a more domain model fashion. I'll also point out yet another issue with the original logical model when it comes to actually using it, which I'll also offer up a solution for. More...