February 2008 Entries

There is an extra day this year.  What are you doing with it?  Take some time today to relish in the fact that you have one more opportunity to tell someone how much you appreciate them.  Perhaps it is your coworker who never breaks the build.  Perhaps it is your boss who calmly listens to your rants.  Perhaps it is your spouse who patiently waits for you to finish your blog.
Regardless, show your appreciation, not by saying "Thank you", but by saying "I appreciate you because..."

Cheers,
Will

As much as I have enjoyed playing with the Entity Framework (Beta 3), I will be uninstalling shortly after this post.  The fact of the matter is, my company is not prepared to go to production in a couple of months with something that hasn't seen a lot of action.  The EF certainly seems stable enough, but, I can respect this decision.

The good news is that we are still using VS 2008 & .Net 3.5.

Also, my plan is to maintain a design that we can migrate to the EF without too much effort.  Hopefully in a few months we will have met that goal.

While playing with Linq and trying to get it to work with Oracle (Linq to Oracle *sigh*), I struggled with the fact that Linq appears to tightly couple business objects with data/persistence. 

I found myself pondering this fact and trying different approaches to separate the ObjectContext from EntityContext(s).  In Linq, the ObjectContext is the object that you provide with a connection string and has the knowledge to send/receive data to/from your database.  The EntityContext(s) are the classes that define your domain model, including relationships.  I looked at various ways to attempt this separation and none of them panned out.  My ultimate goal was to have the classes in separate libraries, but, the classes are generated and are in the same file. 

I even contacted the great guys responsible for Linq (check out Dinesh's Cyberstation), and they provided very useful input.  However, I finally decided to take a step back and ask myself why was it so hard to force what I wanted.  Was Linq a fit for my design?  After careful consideration, I answer "No, but..."  What it really comes down to is years of experience with mediocre designs.  What I wanted to do is extend the EntityObjects to add my business logic.  Perhaps there is better way.

Think about the Single Responsibility Principle (cohesion).  Am I trying to make my "business objects" do too much?  I wanted to put validation logic and other actions in a partial class to extend the EntityObject.  If I were to do that, there would be a lot going on in that class ("There should never be more than one reason for a class to change.").  Validation logic can be handled by separate validator classes (or a framework like Spring.Net).  And, "other actions" sounds a bit fishy.

I have become a fan of MVC/MVP.  (I promised a review of Microsoft's MVC Toolkit (.Net 3.5 - MVC), but I haven't gotten there yet.)  I think a lot of people don't understand that the real benefit behind MVC is not in simplifying the UI code.  That is just a nice side effect.  The real benefit is moving business "logic" or "flow" to one place, the Controller.  You don't even have to have a UI to take advantage of MVC.   In fact, I think that this is where "other actions" belong.  Let the Controller be responsible for coordinating all of the objects involved in these "actions".  Of course, don't let MVC become your hammer and try to see everything as a nail.

In summary, Linq has forced me to rethink my design.  In the end, I think that is a good thing.  I have had to remind my self of design principles that are easily forgotten.  So, I will let Linq do what it is good at, and I will build other classes that are each good something else.

Well, I have been playing with Linq, specifically with Oracle.  First of all, the only way I could find to make this work is to use a third party software, OraDirect.Net by Core Lab.  Their product is great.   Perhaps that statement is biased by the fact that they are the only one's building a library to support Linq to Sql (as far as I know). 

There is certainly room for improvement.  I've crashed VS a few times because I was trying to force OraDirect to do something it doesn't support.  So, error handling needs some work.  Also, there are still a few too many things that require manual labor (I guess I am getting lazy in my old age).  Regardless, the guys at Core Lab are working really hard to address the barrage of feedback on their product.

I really like the fact that MSBuild is installed with the .Net Framework so you do not have to install a separate build tool. Unfortunately, if you are developing Web Application projects (WAP), you may discover something is missing.

In my case, I am building a VS2008 project and the build server does not have Visual Studio installed. No problem, right? Wrong.

It turns out that when you install VS, it deploys some additional targets to the MSBuildExtensionsPath. Without these targets, when you run the build, you will see:

This is in direct reference to your WAP *.csproj file.

If you search for MSB4019, you will find a few different resolutions. Here are a couple.

1. Add a condition to the <Import> element that basically verifies the target file exists. Because you are modifying your csproj file directly, VS may warn you about it. I am not a great fan of this approach, but it appears to work. I think perhaps the reason is because the import is only necessary when building the project from within VS.
2. Deploy the target files to your build server. I copied the entire contents of <MSBuildExtensionsPath>/Microsoft/Visual Studio from my development box (which has VS2008 installed) to the build server.

The same issue arises with VS2005.

Anyway, I hope this clarifies the issue and helps someone.

I received the "okay" today to develop our new application in .Net 3.5.  This is really great news.  I am looking forward to taking advantage of some of the new technologies available. 

In particular, I will be checking out the MVC Toolkit that Microsoft offers as an add-on.  I have implemented MVC/MVP in previous versions of ASP.Net.  The experience was cumbersome at best.  The real issue I had is that it was really difficult to move the appropriate pieces out of the view and that the view knew too much about the controller.  These problems existed because to render an ASP.Net page you had to start with the view.  With the MVC toolkit, the web requests go directly to the controller and the controller decides (as it should) which view to render.  Scott Guthrie has a series of posts that are very helpful if you want to learn more (Scott Gu - MVC).

I plan to play with the MVC Toolkit over the next week or so and come back here with my experience.  I have high hopes.

I've been working on the Statement of Work (SOW) for the new project I am involved with.  The client is looking for a lot of detail.  Initially, I shared my concern about putting too much detail in this document so early in the project.  We discussed the fact that we will learn a lot as the project progresses and the SOW could become severely out of date.

It felt like I would be wasting a lot of time on the details.  I've decided, however, that there are some advantages to this work.  First, there have been some new discoveries.  This project has a fixed budget and fixed time line.  So, identifying more about the project up front is helping us to determine what we can put in the scope and what will have to wait.  Certainly, this will change as we go, but it is nice to have a better understanding of the scope.  Second, as part of Iteration 0, we can use this information to get a rough idea what the overall architecture will be.  Now we know what type of servers we are going to need and a rough idea what services we may need to build.  Who knows, maybe I will discover other advantages later.

Ultimately, I still think we put a bit too much in the SOW, but it may have been worth for the advantages we gained.  The question I am asking myself now is, "Where do you draw the line when composing a SOW while keeping inline with Agile principles."  This is something that will require more thought, research and experience.

Last week I started working on the build scripts for my new project.  I've worked on build environments in the past, but I didn't really commit everything to memory.  Thus, I have had to reinvent the wheel in some ways.  So far I have established commit and nightly builds.  Each build cleans up after the previous build, retrieves the latest source, compiles the application, and runs the tests under coverage.  The tools of choice: CruiseControl.Net, Subversion, NUnit, NCover, and MSBuild.

Originally, I planned to use NAnt because I had used it in the past and was somewhat familiar with it.  However, as I am developing on .Net 3.x and using Visual Studio 2008, I decided to take a look at MSBuild.  I did quite a bit of Googling before getting started to look for comparisons between NAnt and MSBuild.  As you can imagine, there were quite a few opinions.  What I discovered is that NAnt seems to give more power where MSBuild can be more usable for build newcomers.  I am not exactly a newcomer, but it has been a while since I used NAnt and I really don't need the power it provides.  This is what led me to use MSBuild.  Ultimately, after a couple of hours of research, it turned out to be relatively straight forward to put together a build script.

One of the nice advantages of MSBuild is that it is packaged with the .Net Framework.  Also, there is a nice MSBuild folder where you can dump common target files.  This is also where I deployed the MSBuildCommunityTasks extension that I use to integrate with SVN.  This folder is easily referenced using a built in property: MSBuildExtensionsPath.  If you are like me, then you probably have more than one project to maintain.  Because of this, I have moved common targets (like getting the latest source) to this folder.  In fact, as the build process will basically be the same for all of my projects, I have put most of my targets in the common file.  All I have to do is import the common target file in my project and set a few properties.  This works out quite nicely and allows me to streamline my project build file.  It also reduces copy/paste reuse.

I still have a ways to go.  I have only been playing with build configuration on my local machine.  I have some rough documentation on the process that I expect to refine when I repeat it on the build server.  Also, I haven't done anything with the database yet.  Check out Snapshot or Change Scripts? regarding my thoughts on the subject.  I think I have decided on using change scripts, but as I haven't tried it yet, I reserve the right to change my mind.