This is an archive of blog posts from a "long time ago". If you find this useful, let me know and I'll revive it.

code blog foo - tag line bar

Dynamic ASP.NET MVC - Part 7, Oak Projections in Massive

So far we've got blog titles showing up on the front page and we've added the ability to create new blog posts. Let's enhance the front page a little bit. Instead of just showing the title, we'll add the title and a summary of the blog posts on the front page (the summary being the first 50 characters of the body).

Extending the Blog Model to Incorporate Summary

We could just do a trim of the body inside of razor, but that's not really reusable. So we are going to add the property to Blog:

Projections

Now that Blog has the concept of Summary, we need to ensure that all the queries from the Massive return Blog. Inside of oak, Massive has been changed to incorporate the concept of "Projections". To demonstrate:

By providing this Func<dynamic, dyanmic>, all queries in Massive will return the projection defined in the constructor.

Changing the View to Include the Summary

Now that we have added the Oak Projection. We can show the Summary in the view. We'll (of course), start with the SeedController:

Last Dialog With Myself

Why isn't the Projection concept in Massive?

Dunno. But the beauty of open source and NuGet is the ability to bring source into your solution and do what you deem necessary to make things work for your application. All the projects (oak, specwatchr, rake-dot-net, nspec, and massive) are on github.

There is so much open source stuff in this project, is it safe to rely on so many external dependencies that aren't provided to me by Microsoft. What if these things change? Open source software varies in quality and support. How do I know they wont make a breaking change in future versions.

I can appreciate this sentiment. The open source libraries are all under permissive licenses (it's okay to use for commercial purposes). Hate to say this, but at some point in time, the open source libraries will evolve and will break current implementations (the .Net framework has had breaking changes too by the way). But. That's. Why. We. Write. Tests. It allows us to be receptive to change. So when libraries change, just try incorporating the changes into your project. If it doesn't break any of your tests, then you're gold.

Taking a test driven approach won't catch all bugs.

You're right. And for those instances, you'll get the yellow screen of death. It's okay :-) Just write the failing test, make it pass, and that same bug will never show up again.

There is still a lot of dynamic stuff in this solution. What if something changes. The test can't catch everything.

Try it out. Change something in this solution and see if you get a failing test. One of my colleagues at Improving Enterprises named Greg Vaughn made a point that really resonated with me: The definition of legacy code is a code base you are afraid to change (regardless of whether it has tests or not). If you don't feel confident about making changes in your source code (statically typed or dynamic...tests or no tests), then you've got some larger problems to solve. If dynamic still feels like too much, a lot of the concepts discussed in this series can still be applied to your existing solutions. Wouldn't you agree?

NSpec is freaking awesome, it provides a great way to incrementally define specifications and context.

I know! Thanks to Matt Florence for creating such a great testing framework.

Parting Thoughts

I think this picture says it all:

"We accept the reality of the world with which we are presented." The Truman Show (1998)
iwdrm.tumblr.com

Always challenge what you have been taught or told. And more importantly, always have a humble and open mind to new ways of developing software.

Taking Development to the Next Level

The features of Oak I've shown in this blog series is only the tip of this ice berg of awesomeness. Head over to Oak's GitHub page to see all the incredible things you can do with this stack.


Written: 6/27/2011