I've had quite a few emails lately about the code sample colouring used on the website and where people can get it. I use a plugin named "Copy Source as Html" for the code samples on the blog so in a very cool way it simply uses my Visual Studio settings.
The style is named Son of Obsidian and it can be downloaded from the really neat Studio Styles website.
The blog has been pretty quiet lately as I've been working on two Windows Phone 7 applications, the first for general release on the marketplace and the second for a local competition, so fingers crossed in win.
Rebuilding Compiled Experience
A long time ago I wrote a few posts about using "Domain Driven Design"-esque repositories using Linq to SQL ("Domain Driven Design Repositories in Linq to SQL"). I still use that general pattern with a few tweaks with extra layer of a "Unit of Work" to manage context lifetimes. I'm using this rebuild as a chance to play with Entity Framework 4 and so need to implement the appropriate interfaces all over again. The only major functionality change will be bringing in support for Entity Frameworks "Include".
I'm not going to go over the full pattern here, just the new parts for Entity Framework, the IRepository interface has changed that GetAll returns an interface IQuery which is pretty much the IQueryable interface with the Include method.
The implementations for IQuery and IRepository are as follows.
public class EntityRepository<T> : IRepository<T> where T : class
{
private readonly ObjectSet<T> objectSet;
public EntityRepository(ObjectSet<T> objectSet)
{
this.objectSet = objectSet;
}
public IQuery<T> GetAll()
{
return new EntityQuery<T>(objectSet);
}
public void Save(T entity)
{
if (entity == null)
throw new ArgumentNullException("entity");
objectSet.AddObject(entity);
}
public void Update(T entity)
{
if (entity == null)
throw new ArgumentNullException("entity");
objectSet.Attach(entity);
}
public void Delete(T entity)
{
if (entity == null)
throw new ArgumentNullException("entity");
objectSet.DeleteObject(entity);
}
}
public class EntityQuery<T> : IQuery<T>
{
private readonly ObjectQuery<T> query;
public EntityQuery(ObjectQuery<T> query)
{
this.query = query;
}
public IQuery<T> Include(string path)
{
return new EntityQuery<T>(query.Include(path));
}
IEnumerator<T> IEnumerable<T>.GetEnumerator()
{
return ((IEnumerable<T>)query).GetEnumerator();
}
IEnumerator IEnumerable.GetEnumerator()
{
return ((IEnumerable)query).GetEnumerator();
}
Expression IQueryable.Expression
{
get
{
return ((IQueryable)query).Expression;
}
}
Type IQueryable.ElementType
{
get
{
return ((IQueryable)query).ElementType;
}
}
IQueryProvider IQueryable.Provider
{
get
{
return ((IQueryable)query).Provider;
}
}
}
The actual Repository that gets used by the domain layer simply delegates all it's work back to a internal repository based off the current unit of work. This is important section because it decouples the domain repository from repository doing the actual work and allows me to change the underlying data source if necessary.
public class Repository<T> : IRepository<T> where T : class
{
private static IRepository<T> Current
{
get
{
return UnitOfWork.Current.CreateRepository<T>();
}
}
public virtual IQuery<T> GetAll()
{
return Current.GetAll();
}
public virtual void Save(T entity)
{
if (entity == null)
throw new ArgumentNullException("entity");
Current.Save(entity);
}
public virtual void Update(T entity)
{
if (entity == null)
throw new ArgumentNullException("entity");
Current.Update(entity);
}
public virtual void Delete(T entity)
{
if (entity == null)
throw new ArgumentNullException("entity");
Current.Delete(entity);
}
}
I'll get into the Unit of Work stuff in my next post.
Rebuilding Compiled Experience
It's been a long time since my last post and for that I apologise, my work and personal lives got the better of me. I find I'm a more regular post when I have a series of posts in mind and a clear direction for my writing so I'll be trying to do more of that.
Over the last few months there's been a huge amount of technology released from Microsoft, new versions of Silverlight and the .NET Framework, Azure and the Windows Phone. I'd like to start to work with some of this and document my experiences. As Rob Conery says "Be a Good Jedi: Build Your Own Blog", technically already done, but a rebuild with new technology is a great way to learn better (or possibly worse) ways of doing things.
So Compiled Experience will be rebuilt initially with ASP.NET MVC 2 and Entity Framework (the current version is NHibernate), I'll hopefully be able to integrate some Silverlight into it somewhere as well. I want to try out ELMAH and also have been using the .LESS CSS recently so I'll be using that. This is just the initial technology list I'm sure it may change as things progress and I don't want to limit myself too much yet.
Beyond technologies I really want to push myself to some TDD, without some discipline I find myself in a "Test Later" mindset so trying to get those tests written first will be a challenge. The other challenge will be to ensure any bugs I come across are first verified with a failing test rather than just jumping into the code and trying to fix the issue.
If you've got any questions, comments or suggestions then please let me know.
So a few weeks I was sent a license to NDepend by Patrick Smacchia and asked if I'd discuss it if I found it useful. NDepend is an analysis tool that tries to help in understanding the metrics of .NET assemblies, one very interesting feature is the ability to query yourcodebase using CQL (Code Query Language).
Being the typical geek I fired up it and pointed at an old codebase, once it was done I was blown away by the amount of information available to me, maybe a little too much. By default the UI feels very busy but I suspect that may lessen once I grow used to using it. The getting started demos helped a huge amount at explaining what I was looking at.
By default there are also a huge selection of built in CQL queries that can provide warnings and errors during the analysis process, for instance warning about classes with too many methods (WARN IF Count > 0 IN SELECT TOP 10 TYPES WHERENbMethods > 20 ORDER BY NbMethods DESC ). Being able to define a teams coding principles into solid rules that can be integrated into a CI process would really be interesting (NDepend comes with MSBuild and Nant tasks).
Overall my initial impressions are favourable, it feels a lot like Resharper in that initially it can feel like too much is in your face and can force people away, but I feel that like Resharper this could be a very useful tool in the long run.
Wow that took a seriously long time, Vodafone customer service was the worst I've experienced in many years. This was a little gotcha I experienced while at "Expression For Arts Sake" and took me a bit to work out what was going wrong.
.NET Ria Services is an interesting piece of technology, in my mind it's the love child of ADO.NET Data Services and Dynamic Data. The ability to expose your model over the wire to a Rich Internet Application including data annotations to assist in scaffolding a working UI on the other end. I haven't had too much of a play yet, I'm hoping it's as extensible as Dynamic Data and MVC such that I can plug in different ways to compose that model (not just attributes on Metadata classes).
Given that the point of EFAS was to play with new technology I thought I'd try RIA Services as the technology to pull data down from my website and database. Setting it was pretty quick, but for the life of me I couldn't get it to work. Visual Studio was complaining about missing classes and namespaces. After about an hour of pulling my hair out and trying the simplest scenarios it still wouldn't recognise the generated DomainContext and classes. This is what Visual Studio looked like.
And then I just hit build and it did! After recovering from shock I realised what had happened. Turning Resharper off suddenly Visual Studio looked like this.
The reason is that the client side code for RIA Services isn't "technically" part of the Silverlight project. It's just in a folder named "Generated Code" that Visual Studio includes as part of it's intellisense and build steps. This means that add ins like Resharper don't believe it's part of the project and throw up errors as before.
I'd really like to see RIA Services follow the more traditional Service Reference pattern with an option to "Update Service Reference on project build" to get around shared code and so on. This was the generated proxy is part of the project and avoids yet another way to have generated code.
Hope this saves someone some frustration.
