Packaging my gallery code

In this posting I describe how I prepare my gallery application for automated testing. As a first thing I plan to write some unit tests because some of my classes have now logic to be tested. The other thing is database that is living outside my Visual Studio solution. Let’s make now first steps in my gallery code packaging.

This far I made things work on new technologies introduced by Visual Studio 2010. I tried to use my own code and I made some design modifications. Now I feel like I am back at safe waters and my next steps on model and UI are pretty much predictable. As there is not much code written already it is good time to make some modifications to my solution’s packaging. You can read more about my gallery project from MyGallery2010 page. Also feel free to drop a comment if you agree or disagree with me. :)

Separating code to packages

Currently I have all my stuff in same project. It was good when I tried out new features because I was able to do it very fast without separating pieces of code to different libraries. When we look at screenshot on right we can see that there are all things in same project:

• business classes like GalleryItem, Album and Photo,
• MyGalleryEntities model and data context class MyGalleryEntities.

What we cannot see here is the database. But it exists and Visual Studio supports also SQL Server database projects.

Also I want to start writing tests for my gallery classes and this is the main motivation to separate current code to different libraries and projects. So, looking and current project structure and considering needs described above I think about following projects in solution:

1. ASP.NET MVC Web Application – web application with models, views, controllers etc.
2. MyGallery2010.Core – class library that contains business classes and interfaces.
3. MyGallery2010.Database – SQL Server 2008 database project that contains definitions for database objects like tables, primary keys and foreign keys.
4. MyGallery2010.Core.Tests.Unit – test project with unit tests for MyGallery2010.Core.

Is it enough?

In this point I stop because this projects structure is enough for now. Of course I can think further and separate more things to libraries but I don’t really want to make things too complex right now as there is no need for that. I know guys who create mega projects structure even for small and simple desktop applications. This far life has shown one thing – overhead caused by heavy packaging eats a lot of time and slows down development. Also it produces no additional value.

So, let’s make no pointless work we don’t need in this point. Let’s get this simple packaging work done and let’s see then what modifications are next most important ones. I am pretty sure that these modifications introduce needs to some more changes in current code and maybe even in packaging structure.

Restructuring projects

When restructuring your project, never make too big steps because otherwise you have big and complex modifications chain to solve. Changes caused by restructuring have usually bigger impact on code that changing some classes. This is why it is good to go with it in earlier stages in project but not before you can see what kind of packages you really need.

You can find out more from these books: Code Complete 2 and Working Effectively with Legacy Code (I have read both of these books and I strongly recommend them to developers).