Jeffrey Palermo, Microsoft MVP, Author, Speaker, Clear Measure Chief Architect, Azure DevOps Expert
If you read twitter, you can find me at http://twitter.com/jeffreypalermo
Since I tend not to write short blog posts (like this one), I put the small ones on twitter.
If you do twitter RSS, you can use this feed: http://twitter.com/statuses/user_timeline/13253882.rss
And normal blog feed: http://feeds.feedburner.com/jeffreypalermo
Since Eric Hexter and I started the MvcContrib project, we’ve mandated a high test coverage. If a patch comes without tests, we’d reject the patch.
Given that MvcContrib exists for the purpose of supplementing a presentation library, ASP.NET MVC, you might think it’s not possible to achieve such a high percentage.
If you were ever curious about how this is done, I invite you to take a look at the project. The project has 1058 tests at this point and the main MvcContrib.dll assembly has 99% test coverage.
As an aside, when code is test-driven, the test coverage naturally falls out of this.
By the way, Eric just released version 0.0.1.118 of MvcContrib to CodePlex.
Keep tabs on MvcContrib by following my feed: http://feeds.feedburner.com/jeffreypalermo
I’m amazed that there is so much talk about object/relational mappers these days. Pleased, but amazed. I tend to be in the “early adopter” part of the Rogers technology adoption curve. (Subscribe to my feed: http://feeds.feedburner.com/jeffreypalermo)
In the .Net world, I didn’t hear much talk about O/R Mappers in the early 2000s. I started working with NHibernate in 2005 while on a project with Jeremy Miller, Steve Donie, Jim Matthews, and Bret Pettichord. I researched, but never used, other O/R Mappers available at the time. Now, in 2008, I find that O/R Mappers in the .Net world are still in the early adopter part of the adoption curve. We have not yet hit early majority, but we have left the innovators section.
Microsoft has single-handedly pushed O/R Mapping to the center of conversation, and we struggle to objectively differentiate between the choices. Arguments like “Tool X rocks”, or “Tool Y sucks” are hard to understand. I’d like to more objectively discuss the basis on which we should accept or reject an O/R Mapper. As always, it depends on context.
Context 1: Small, disposable application: In this case, we would put a premium on time to market while accepting technical debt given the application has a known lifespan. For this type of of situation, I think it depends on the skill set of the team we start with. If the team already knows an O/R Mapper, the team should probably stick with it since the learning curve of any other tool would slow down delivery.
Context 2: Complex line-of-business application: Here, the business is making an investment by building a system that is expected to yield return on the engineering investment. The life of the application is unbounded, so maintainability is king. We still want to be able to build quickly, but long-term cost of ownership has a heavy hand in decisions. Here, we have to objectively think about the tools used by the system.
I’ll use O/R Mappers in this example. On the right is a common visual studio solution structure. We would probably leverage the O/R Mapper in the DataAccess project. I consider the O/R Mapper to be infrastructure since it doesn’t add business value to the application. It merely is plumbing to help the application function. By following the references, we find that our business logic is coupled to the data access approach we choose as well as infrastructure we employ. Often we can build the system like this, and we can even keep the defect rate really low. This is very common, and I’d venture to guess that most readers have some experience with this type of structure. The problem with this structure is long-term maintainability. In keeping with the O/R Mapper decision, five years ago, I was not using NHibernate. If I ask myself if I’ll be using NHibernate five years from now, I have to assume that I probably won’t be, given the pace of technology. If this system has a chance of maintainability five years from now, I need to be able to upgrade parts of the system that are most affected by the pace of technology, like data access. My business logic shouldn’t be held hostage by the data access decision I made back in 2008. I don’t believe it’s a justified business position to say that when technology moves on, we will rewrite entire systems to keep up. Sadly, most of the industry operates this way.
On the left is the general solution structure I’m more in favor of. You see that the core of the application doesn’t reference my other projects. The core project (give it whatever name you like) contains all my business logic, namely the domain model and supporting logical services that give my application its unique behaviors. Add a presentation layer for some screens, and the system delivers business value. Here, you see I’ve lumped data access in with infrastructure. Data access is just not that interesting, and system users don’t give a hoot how we write to the database. As long as the system is usable and has good response times, they are happy. After all, they are most happy when they are _not_ using the system. They don’t spend their leisure time using our system.
I consider data access to be infrastructure because it changes every year or two. Also consider communication protocols like ASMX, remoting, WCF to be infrastructure. WCF, too, will pass in a year or 10 for the next wave of communication protocols that “will solve all our business problems”. Given this reality, it’s best not to couple the application to infrastructure. Any application today that is coupled to Enterprise Library data access will likely have to be completely rewritten in order to take advantage of any newer data access method. I’d venture to say that the management that approved the budget for the creation of said system didn’t know that a rewrite would be eminent in just 4 short years.
How do we ensure the long-term maintainability of our systems in the face of constantly changing infrastructure? The answer: Don’t couple to infrastructure. Regardless of the O/R Mapping tool you choose, don’t couple to it. The core of your application should not know or care what data access library you are using. I am a big fan of NHibernate right now, but I still keep it at arms length and banished to forever live in the Infrastructure project in the solution. I know that when I want to dump NHibernate for the next thing, it won’t be a big deal
How do I ensure I’m not coupled to my O/R Mapper?
The key is in the flipped project reference. Have the infrastructure project reference the core, not the other way around. My core project has no reference to NHibernate.dll. The UI project has not reference either. Only in the infrastructure project.
Keep it easy to dump NHibernate when its time has come
For now, NHibernate is the O/RM of choice in .Net-land. When it’s time comes, don’t go to management and recommend a rewrite of the system because it’s completely tightly-coupled to NHibernate. Keep NHibernate off to the side so you can slide in the next data access library that comes along. If you tightly couple to your O/RM, you’ll sacrifice long-term maintainability.
When choosing an O/R Mapper: The objective criteria I think is most compelling is to determine of the library allows isolation. If the tool forces you to create an application around it, move on for a better one. The good libraries stay out of the way. If your O/R M always wants to be the center of attention, dump it for one that’s more humble. Use an O/R M that plays well behind a wall of interfaces. Beware the O/R M that doesn’t allow loose coupling. If you tightly couple, it’s a guaranteed rewrite when you decide to change data access strategies.
We have received many patches that keep making MvcContrib THE library for extra functionality on top of the ASP.NET MVC Framework.
RSVP now for the HUGE Tech Ed Developers edition of Party with Palermo. I’ve rented out an entire night club right down from the convention center for this party. Bring your friends and your business card.
If you have a blog, please add this badge:
The Austin .Net User Group conducted its third annual Austin Code Camp on May 17, 2008. Eric Hexter and John Teague did a great job heading up the effort to put on this weekend conference. Attendance was around 203, and St. Edward’s PEC graciously hosted again. Those facilities are great!!
I was returning from the DevTeach conference in Toronto, so I had to miss. Very unfortunate. I was able to vicariously experience it through reading second-hand reports from some of the attendees.
Peter Seale provided some encouragement that the focus of the Austin .Net User Group is on the right track with his report of the code camp.
“The code camp did not feature an “Introduction to Silverlight” session. This is the simple, effective test by which I will measure all future conferences: is there an intro to Silverlight session. If there is, then good chances are most of the sessions will be useless. Further down the road, change out “Silverlight” with whatever new UI framework/data grid/designer tool that is “up to two years away from release.” I’m officially tired of these type of talks, 4 LIFE. Call me back when you’re running a “Best Practices in Silverlight Smackdown.”
The code camp was heavy on OO principles. This is a good thing; between “patterns cage match” and “IoC jumpstart” and “OO design” and “mocks and stubs”, my brain was assaulted by lots of OO. Which is good, I haven’t gotten this much in the 3+ years of involvement with Houston user groups and events. Not to gripe on my home city, let’s stay positive etc.”
Others have also provided thier thoughts about the conference:
A quick tip about scripting a software build using SQL Express 2005. It isn’t network-enabled by default, so you’ll want to change the network configuration to enable TCP/IP. The setting is in Sql Server Configuration Manager. Here is a screenshot: And I used Cropper on x64 windows to make the screenshot.
I recently tried out Windows Server 2008 x64, and I’m gradually transitioning. I’m installing all the tools I have on my XP drive, but I won’t complete the switch until I’ve verified there are no blocking issues.
I regularly use Cropper to grab snapshots of my screens and portions of them. I tried running it, and it failed spectacularly! I decided to grab the code from CodePlex and see why it was failing. I ran through and was able to fix the issues. The main issue was that it was built against .Net 2.0 with Any CPU, but it depends on Win32 APIs. I switched the build configurations to x86, refactored an assembly load problem buried in a static constructor, modified the MSI setup project, and it started working.
I’ve submitted a patch back to the CodePlex project, so if you need Cropper on x64 Vista or Server08, you can grab the code with TortoiseSVN, apply the patch and make your own build. I’ve sent Brian a note, so I’m hoping he’ll either add me to the project or apply the patch soon.
I used SvnBridge to pull down the source code. I didn’t want to install Team Explorer JUST to pull down one project. I’m happy to report that SvnBridge 2.0 worked very well. I followed the instructions here for pulling down the source code with TortoiseSVN.
My session materials are posted here on my
google code repository
Blackbelt configuration for new projects
Jeffrey
Palermo – ARC439
Any architect knows the challenges of setting up
configuration management for a new project. Architecture isn’t just for the
application. The manner in which source control, dependencies, and the Visual
Studio solution is set up can have profound impacts on the productivity of the
team. In this session, we’ll set up a source control repository, a VS.Net
solution and a build script to enable a team to move quickly on the project.
We’ll used advanced techniques to reduce friction while working with the code
base on a day-to-day basis.
ASP.NET MVC Framework Submersion
Jeffrey Palermo –
NET328
The move from ASP 3.0 to ASP.Net was a very dramatic move, and it
forced developers to learn a completely new way for building web applications on
Windows servers. From Web projects with v1.1 to websites in v2.0 and then web
application projects in v2.0+ , working with ASP.Net can be a more difficult
than necessary due to viewstate, postbacks and the control lifecycle for
post-back eventing. Microsoft is providing an extension to ASP.NET to provide an
easy way to implement the Model-View-Controller pattern using ASPX as a view
engine (templating). With all presentation logic residing in the Controller, the
View (ASPX) is left to concentrate on what it does best: rendering html. This
new MVC framework is pluggable and testable and even allows for Controller
classes to be created with your IoC container of choice. This presentation will
include a primer on programming with the MVC pattern and will also cover unit
testing controllers and creating controllers that use dependency injection.
Eric Hexter has already announced his move to Headspring Systems. I am very glad to have him on board. I look forward to the contribution he will make to our company. He brings many years of experience from being the Director of eCommerce Technologies at Callaway Golf Interactive. He joins us as a Principal Consultant.
Eric is very influential in the central Texas .Net developer community, and he is one of the Directors of the Austin .Net User Group. He also is a co-chair of the Austin Code Camp that is happening this weekend.
Eric is also a co-founder of the MvcContrib open source project that compliments the ASP.NET MVC Framework. Along with that, he’s done quite a bit of research on how to write automated tests for Silverlight applications.
Eric, welcome to the team!!
Subscribe to the feed for all the updates