Derik Whittaker

"Operation could destabilize the runtime" from Casting from Concrete to Interfaces with Linq

Derik Whittaker — Sat, 29 Nov 2008 16:19:43 GMT

In all my years of doing .Net I have to say that I finally came across the exception message that takes the cake. Today while trying to do some refactoring on the DimeCasts.net code base I received this exception.

Operation could destabilize the runtime

I received the error while trying to update some Linq-2-Sql code that where I was trying to return the data as IList<IDownloadInformation> (yes I killed the delayed execution). Below is the code that caused the exception

public IList<IDownloadInformation> FetchEpisodeDownloads( Int32 episodeID )
{
	var result = ( from d in DBContextInstance().EpisodeDownloadInformations
        	where d.EpisodeID == episodeID
		select (IDownloadInformation)new DownloadInformation()
                	{
                        DownloadID = d.ID,
                        EpisodeID = d.EpisodeID,
                        ...
                        
                       	);

	return (IList<IDownloadInformation>) result.ToList();
}

Turns out the above code works, mostly. Everything is fine until I went to cast the return results. It was then I received the nice exception.

As soon as I found the error I hit Google for some help. I was able to find this post which helped to point me in the right direction.

After taking a look at my code again, I was able to get the code below to work (this time I decided to use IQueryable so I could get the delayed execution.

        
public IQueryable<IDownloadInformation> FetchEpisodeDownloads( Int32 episodeID )
{
	var result = ( from d in DBContextInstance().EpisodeDownloadInformations
        	where d.EpisodeID == episodeID
                	select (IDownloadInformation)new DownloadInformation()
                        {
                        	DownloadID = d.ID,
                                EpisodeID = d.EpisodeID,
                                ..                                 
			}
			);

	return result.OfType<IDownloadInformation>();
}

Using the built in OfType support to cast your return value back to the interface seemed to work and it is pretty clean and simple. What is funny about the actual exception that was thrown is that it makes no sense and really does not lead you to the problem. Gotta love Google :)

Hope this helps.

Till next time,

[--- Check out www.Dimecasts.net ---]

RenderPartial vs RenderAction

Derik Whittaker — Mon, 24 Nov 2008 22:08:52 GMT

If you have been using the MVC framework I am sure you are aware that in many cases there are multiple ways to accomplish the same task. One such case in point is how to render content for a View. Now I am not talking about how to render an entire View, but rather how do I render partial Views (aka user controls).

Let me paint you this picture. In your master page you have some common content you want to render in every view and this content needs to hit the business layer to perform some sort of logic. How do you generate this content (the end result is like what you see to the right)? The HTML content to the right is generated in a User Control so it is completely isolated from my main view or master page.

There are at least 2 different ways you can include data into your View and both of them have their pros and cons, but I personally feel one stands out as the clear favorite.

Approach 1: Using Html.RenderPartial

One way to render a user control is to use the Html.RenderPartial helper. This will accept the name of the user control to render and optionally the data that is needed to build the user control. You can see a simple example below.

<% Html.RenderPartial( "SomeControl.ascx", ViewData.Model ); %>

This works well and can be very useful, but lets take a look at the pros/cons with this approach.

Pros:

Simple to use, no need to create any controller actions

Cons:

Your view now has intimate knowledge of not only which user control/partial is should render, but how to find it.
Your view need to provide the data to another view and this in itself has two issues

Your view has to be aware of how it should populate other entities, this should NOT be the views job as this is business related logic.
Because you can provide data, you could be tempted to skip the controller layer (aka traffic cop) and simply make a direct call to into your service layer, or worse yet directly into the database

Approach 2: Using Html.RenderAction (in Microsoft.Web.Mvc)

Another way to render a user control is to follow the same process as you would to render your View. Let the controller determine which view (aka partial or user control) to render. You can accomplish this by using Html.RenderAction (which is part of Microsoft.Web.MVC assembly). This will allow you to specify a controller action to call which will determine which view/partial/user control to render. Take a look at the simple example below for how to use RenderAction.

<% Html.RenderAction<MyController>( x => x.ControllerAction() ); %>

I feel that this works well and can be useful, but lets take a look at the pros/cons with this approach.

Pros:

You let your controller action do what it does, perform organizational logic and can make requests into the business layer to perform business logic.
Abstracts away which actual view/partial/usercontrol is going to be used in this location. This is nice because it allows for simpler refactoring in the future.
Abstracts away any business related logic into the controller. This helps with keeping your business logic in the correct place
Is strongly typed since it uses lambdas.

Cons:

You have to create another controller action to handle the request.

As you can tell from my list of pros/cons I think that calling RenderAction is a far better option.

Till next time,

[---- Visit DimeCasts.net ----]

[ANN] Programming Asp.Net MVC by O'Reilly

Derik Whittaker — Thu, 20 Nov 2008 02:20:00 GMT

Well, it is about time we (Tim, Chris and myself) actually made this announcement. We will be doing a MVC book with O'Reilly titled 'Programming MVC'. We are super excited and super pumped to get this out the door. All three of us are huge fans of the MVC framework and know that this is framework going to be smashing success.

The goal of this book is to provide a clear, concise vision on how to build web applications using the MVC framework. Our goal is to walk you though the various parts of the MVC framework and MVC Pattern to all you to have a solid understanding of what the framework can do for you. Once you have mastered the framework, we will then take you on a little journey on how to use the framework to build out your application. By the end of the book our hope is that you will have a solid enough understanding of the framework be able to build a application, but also to know why it does what it does.

Collectively we will all be posting thoughts/content on the book over the coming months, so please stay tuned for more information.

Wish us luck (and send along some caffeine) we will see you on the flip side.

Till next time,

Testing is hard but debugging just sucks A$$

Derik Whittaker — Fri, 14 Nov 2008 23:58:05 GMT

In my last post (here) I was giving a wrap up of the Mocking session I recently did at TriNug. In that post I gave some of the reasons (sorry, I meant excuses) people gave for not doing any type of automated testing during their dally development ritual (notice I am staying away from TDD at this point). I thought that those topics would be better suited to be broken out into their own post.

At the users group I asked the question to the group 'who creates automated tests as part of their daily development cycle?'. After I asked this question I followed it up with, and if you don't WHY, WHY, WHY, WHY...... Below are some of the answers I received (btw, not the first time I have heard these reasons).

Reason #1 - It is too hard to get started:

Point: This statement is nothing new, I hear this all the time. To be honest I agree with them, testing is hard. It takes time and effort to learn how to do it.

Counter Point: But if you think learning to write tests and learning how to create testable code is hard, then what do you do when you need to learn a new product? I can break it down like this. Testing == Coding and Coding == REAL FREAKING HARD. Stop using 'testing is hard' as a crutch and just give it a shot.

Reason #2 - My client/company is not paying me to write tests:

Point: This one always make me laugh. Since testing does take time (not going to sugar coat this at all), and can slow down your pace of development, many people feel that they are not being paid to create tests.

Counter Point: This one is real simple, ask your self these two questions.

Am I being paid to produce quality or crap?
Am I being paid to debug?

I am going to assume that both of those answers are NO, and if they are not then I would suggest you stop reading this post as it does not get any better from here.

Now that we are on the same page and we understand you are being paid to produce quality code why would you not want to do everything you can to bake that quality into your code up front? This can happen with tests. Take the time, take the challenge and create some tests. Trust me, no one ever got fired for being a bit late with an application that was freaking solid from a quality standpoint (and if you do get fired because of it just look at it this way, you have a new and marketable skill to help you find your new job).

Reason #3 - I do not have time

Point: Testing takes time, and when time is short people throw every 'non-critical' functions out the window. And sadly people think that quality is a non-critical function. To prove this point just take a look at 90% of the applications out there... they suck ASS

Counter Point: Just ask yourself this question. Would I rather spend what little time I have creating tests to help ensure I have quality or would I rather spend time later stepping through code via the debugger looking for the bug I could have caught/fixed earlier? If you would rather spend time in the debugger, then more power to you.

NOTE: Do NOT take the above statement as me saying that testers NEVER debug, they do but just a TON less than others.

Reason #4 - My code will not allow me to tests

Point: This is one may be the only excuse that has some merit. Poor code is hard to test.

Counter Point: Simply because you do not need to retrofit your entire code base at one time. If you have 'bad' code that is easy to test that is fine. Start testing with NEW code. Hopefully you will not be creating bad code once you understand your current code is not the best. You will also come to understand that when you start testing your code will start to get a little cleaner. Finally, if you really want to start to test your legacy code, go out and pick up 'Working Effectively w/ Legacy Code' by Michael Feathers

As you can tell from my tone, I do not buy into any of these reasons, sorry excuses. I wish that when I ask people this question and they gave me a response they would simply state the truth. And the truth is people do not test for the following 2 reasons

Reason #1 - They do not believe that creating tests will improve their code
If this is what you really think, that is fine. You are allowed to have your beliefs and I am allowed to have mine. As long as we understand each other we can get along just fine.

Reason #2 - They are lazy
Not sure I need to explain this one.

Let the flames begin :)

Till next time,

Talking Mocks at TriNug, what a great time, what a great group

Derik Whittaker — Thu, 13 Nov 2008 12:36:01 GMT

Last night I had the opportunity to do my 'Taking your tests to the next level with Mocks' session to the TriNug user group. I would first like to say thanks to Doug Wilson and his entire group. They had a great turn out (45ish people) and they asked a ton of great questions.

To kick off the session I ask the same question I ask everything I give this session 'Who in here writes tests as part of their development routine?'. The response I got did not surprise me, about 30% said they did. I then asked those 30%, who using a mocking framework? Again the response did not surprise me, only about 50%.

Of course with only 30% even saying they test, I had to ask why, why and why. The responses I got I have heard before and thought I would share them

It is too hard to get started
I have heard this one before, and I am not going to lie to you, writing tests is hard, it takes effort and time to learn how to do it. But just ask yourself this. When learning anything new is it easy? Are you able to just pickup a new tool/technology and 'know it' or do you have to learn it? My guess you have to learn it, testing/mocking is no different.
My client/company is not paying me to write tests
Sorry, but this is one statement have to call BS on. I immediately asked, is your company paying you to write shitty quality? Or are they paying you to produce quality code? If they are paying you to write shitty code, STOP reading now as I am done talking to you (ok, may be not, but really??? shitty code is what they want???). If they are paying you to create quality code how can you insure it without tests? My guess is that you have tests, but they just happen to be of the manual, error prone nature.
I do not have time
Again, another one I call BS on. I followed this up with 'let me guess, you have time to debug/bug hunt at the end right?'. The key to testing is that it does take time (wow, that is honest) but it is either a pay me now, or pay me later scenario. Either you take the time now to embed quality or you take the time later to duck-tap quality. Your choice?

With this information in hand, I really attempted to drive home the values of both testing as well as using a mocking framework to remove dependencies. I think towards the end of the night I had converted some people to 'believers' and hopefully they will either give testing a solid go (assuming they are not testing right now) or give using a mocking framework a go.

You can get any of my session information from Google code from this location http://code.google.com/p/graudo/.

Till next time,

[----- Remember to check out DimeCasts.Net -----]

Upcoming Speaking Engagements

Derik Whittaker — Sun, 09 Nov 2008 22:53:07 GMT

Just wanted to send a message out there to anyone that is going to be in the Raleigh/Durham area this week. I will be giving 2 talks this week. One at TriNug and another at the Raleigh Code Camp. If you are in the area and want to stop by to heckle me, please do.

Info on the 2 sessions

TriNug - Taking your Tests to the next level with Mocks

This session will walk through the progression of testing with mocks. We will learn how using mocks, and mocking out dependencies will increase the reliability of your tests. We will also learn why it is important to remove any dependencies that are out of your immediate scope. We will do a quick overview of TDD using NUnit, but the crux of the session will be focused on mocking with RhinoMocks along with the StructureMap AutoMocking Container

Code Camp - Bending the Asp.Net MVC to do Your Bidding, the Virtues of Extensibility

Most frameworks only meet about 80% of our actual needs. This could be due to our unique business needs, because the framework has made some wrong assumptions, or because the framework has a different scope. Therefore, it is the wise framework that recognizes this and builds in extensibility points.
In this session we will learn how to bend the ASP.Net MVC framework to your will. The ASP.Net MVC framework was built with extensibility in mind. Almost every part of it is extensible, from the view engine to the controller factory to the routing engine. We will learn how to make use of the various extension points in the framework and make it do our bidding.

Hope to see everyone out there, both sessions should be great. Even if you have no interest in hearing my MVC talk I encourage you to still attend the Code Camp as there will be great content.

Till next time,

Chicago Alt.Net this Wednesday - Nov 12th

Derik Whittaker — Sun, 09 Nov 2008 22:49:25 GMT

It is time for this months installment of Chicago Alt.Net meeting. You can register here and get more information from our new site (thanks Sergio) at www.chicagoalt.net.

Meeting Information

The Different Views of ASP.NET MVC

6:00 pm
Pizza and networking time

6:30 pm
The default ASPX view engine in ASP.NET MVC is fine and comfortable but as with just about anything in ASP.NET MVC, you can replace it with alternative engines — and there are a few of those available.

We will be giving an overview of some of the alternative view engines, showing how to install and use them, what brought them about, and why would you use them.

Adam Tybor will be presenting Spark,
Mike Hall will show NHaml,
and TBD (not defined, wanna talk?) will talk about Brail.

7:45 pm
You may want to stick around after the presentation portion of the meeting and take part in our monthly open discussion. The topic is never arranged in advance but it's common that it reflects the content of the presentation.

Please register with your real first and last names because you'll need to identify yourself at the Sears Tower front desk. The front desk will have the list of attendees. If you can't register in time, show up anyway and call Sergio (224-627-8352) when you get to the front desk and we will let you in.

I hope everyone has a good time, I am not going to be able to make it this month as I will be out of town on business.

Till next time,

The simplicity that is the Asp.Net MVC

Derik Whittaker — Wed, 05 Nov 2008 11:25:22 GMT

Today I was browsing my list of RSS feeds and I stumbled upon a posting that showed some Asp.Net code. This code was nothing out of the ordinary, it was simply someone building a table with a repeater.

The first thing that came to mind when I saw the markup for the repeater was

'WOW, that looks like crap. Cannot believe anyone likes that markup'

After about another 2 seconds looking at the code I realized how I loved the simplicity of Asp.Net MVC and how its markup is simple, clean and only shows you what is important.

Sure my the markup and lines of code needed by the MVC framework is really no less in total number. But is 100% cleaner in my opinion.

I am sure this line of thinking is nothing new to many of you, but I guess it never dawned on me.

Till next time,

Removing words like Convince, Convert and Persuade from our vocabulary

Derik Whittaker — Tue, 04 Nov 2008 11:26:22 GMT

One of the common themes of this years KaizenConf was how to move a towards being a lean organization. During most of the sessions and conversations that I was part I cannot tell you how often I heard words like Convince, Convert and Persuade said. At first I had nothing against these words, but the more I thought about I know feel that we need to remove those words from our vocabulary when talking about moving a team or organization from one thing to another (in context of these conversations it is towards being lean).

Using terms like Convince and Convert has the feeling that 'I am right and you are wrong'. Even if you are not using terms like Convince and Convert in your dialog with people, I am going to guess that you have that as your goal, or your end game.

I am here to suggest that we as a community need to change our focus from Convincing towards Demonstrating. By changing our angle and our position to be more neutral and soft I feel we can archive our goal of bringing change easier and with less friction. It is like that old saying 'you can catch more fly's with honey than vinegar.

Lets take a look at the subtle differences between Convincing and Demostrating.

When we are trying to Convince someone of something many times we give off the following vibes.

That your way is wrong, and our is right
That we are better and more knowledgeable
That we are preaching

All of above tend to put people on the definsive and if someone is on the definsive they are less likely to be open minded and less likey to want to try to understand what it is you are trying to say.

When we are trying to demostrate something to someone we give off the following vibes.

Heartflet attempt to share knowledge
Cooperation
Alternative to, not a replacement for their way of doing something
Sincere intrest in helping them.

When you speak to someone with the above vibe, you are essentally telling them that I have an idea and I think that my idea can help you out. If you attack it from this angle you may be surprised by the level of reception you can receive.

Remember, convincing someone is never easy, but demostrating alternatives and allowing them to make their own decision can be.

Keep up the good fight and happy demostrating.

Till next time,

KaizenConf Wrap Up -- What an Exhausting Learning Experience

Derik Whittaker — Mon, 03 Nov 2008 00:53:04 GMT

Well, that does it for this years KaizenConf. I can honestly say that I had a great time, I met some great people (nice to put faces to twitter handles) and shared some great stories. What is great is that when I setout to make it to this openspace conference I had a ton of questions. I walk away from the event with a lot of answers, a lot of gained knowledge and not surprisingly more questions.

It may seem odd that I have more questions in the end then in the beginning, but that is a sign of learning. I now know more and this additional knowledge has lead to more questions.

I have posted the wrap-up comments for the 2 sessions where I was the convener (2 of my topics/sessions that I suggested were selected) and you can get them here

The output of all of the sessions are being documented in a Wiki, and you can find it here.

Final thoughts on the conference

Wow, am I exhausted.....! I have been to my share of technology conferences, but I can say I am more exhausted after this one than any other. The reason for this was the amount of engagement and thinking that needed to take place. At most tech conferences you sit back and listen to someone present (or hopefully teach) on a given topic. Not till the end does the audience have a chance to interact.

With this there were no planned sessions (in terms of having PPT slides or code ready) and no one person 'lead' any of the sessions. Each of the sessions were run by the group and went into the direction the group directed (aka as an open space should). During each of these sessions you forced to get involved or you were passed over. because of this involvement you learn a ton, but become exhausted.

I will take a little exhaustion for the amount of knowledge gained over the past few days. :)

I have to say one of the highlights of the weekend was dinner on Friday. A few of us just decided to head back to the hotel bar for dinner and brew. About 30 minutes after we sat down Mary and Tom Poppendieck sat down with us. They are 2 of the nicest, sincere and down to earth people you can meet. Even with all their knowledge and experience we (the entire table) were able to have an open and engaging conversation about lean and continuous learning.

Final thoughts in regards to the name/context change from Alt.Net to KaizenConf

Back when the conference was announce Scott Bellware took a ton of heat for changing the name of the conference from the Alt.Net conference to the Kaizen Conference. Many people in the community really did not see any reason for changing the name and thought that it was done for various self serving reasons.

Having been to the conference, I know understand what his goal/intent was with the conference. This weekends openspaces was NOT about technology. I say that with 100% sincerity. Sure there were topics out there on Rhino, IoC and MassTransit, but that was simply one track out of 5. The majority of the sessions were around how we can help bring change to our organizations and more towards the idea of continuous learning.

Till next time,

KaizenConf - Open Communication, Resistance to Change, Going with the Staus quo w/ reference to various team roles

Derik Whittaker — Sat, 01 Nov 2008 20:20:55 GMT

Another session that I sat in on today was "Open communication, Resistance to change, Going with the status quo with reference to the various roles on the team "

If I could wrap up the entire session in a phrase it would be the following:

When your team feels empowerment and has passion they will be successful

Below are my notes, sorry they are not in a long descriptive form, but they are notes :)

Quotes:

The product champion doesn't figure out what the market wants, but brings the team to the customer
Without a good leader, or a champion of the team your team is doomed to fail
Quailty is building a substainable releationship
the value of value is realitive worth
When you do not have the fear of being fired you can become more open

Questions:

What are the barries to opening communication
- Management/customer sees the release cycle/process as a tax
How are we defining Continous Improvement?
- taking notices of our process our, release cycle
- balancing various items like maintainability, without over engineering our product
What is value????
- this means differnt things to different people
- means that someone will always be unhappy
- operations has more work with more installs -- they are unhappy
- developers have have more pressure if they have more work load
- one persons pain is another persons pleasure
How do we make change when we are capiable of influincing change, but not the permissionr
- start local
- start small
- hope your ideals spread
How do we move from me to we
- get buy in from all on the team goal
- get ownership
- have pride/passion
How do we get a team to become engaged or passionate
- ownership
- self correction, self moderation
- foster that the project will be a success
- stay positive
4 areas of improvement
- improvement of skills on the team
- improvement of the purpose of the product
- improvement of the process
- improvement of the releationships

Till next time,

KaizenConf - Encouraging Change w/ Agile Examples

Derik Whittaker — Sat, 01 Nov 2008 16:46:48 GMT

The first session I sat in today was titled 'Encouraging Change w/ Agile Examples'. This session was the combination of a few others and we took all the ideas and redirected into this.

The intent of the session was to attempt to flush out ideas that will allow us to move our business and our development teams down the path of adopting agile.

The conversation was awesome, we had tons of solid feedback and we able to talk about various real word scenarios.

Below are my notes, sorry they are not in a long descriptive form, but they are notes :)

Resources:

Scrum and XP in the trenches
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

Quotes:

'How are you going to test that?'
'Test to reproduce bugs first'
'If it is hard you're doing it wrong'

Questions:

Moving a team (10 or 11) to move to scrum/xp
- forced team to switch to scrum/xp
- this caused 100% turn over on the team
- forced to move into a team room
- he laid down the law, did not waiver
Team with no process, no methodology
- team struggles with lack of direction
- team struggles with lack of delegated authority
Getting started with TDD/agile process
- start by asking where are your tests
- start by keep mentioning that tests are needed
- using tests to explain intent of code via completed tests
- mentoring developers
- Small pieces, baby steps
- explaining the value
What can we do that provides the most bang for the buck in the short term
- remove scope
- create priority of items that MUST be delivered
- force the company to make decisions, or you will make the decision

General Thoughts:

Done/Releasable is defined as 'what is good enough to be able to produce a release'

Learn to use metrics to lean to convey the status of the project and how
if they want more features in less how this may or may not be possible.

Need to get everyone on the same page in terms of business terms.
- how did you did do your job before we had 'technology'

Rant:

We need to remove the term 'The business' and turn it into 'our business' (Tom Poppendieck on his soap box)

Till next time,

Kaizenconf day 1 wrap up

Derik Whittaker — Sat, 01 Nov 2008 11:52:03 GMT

Yesterday was day 1 of this years KaizenConf and it got started off with a bang. I was not able to make it to most of the conferences pre-conference workshop, but I was able to make it to one.

Fluent APIs with C# - Chad Myers

Chad put together a great workshop about how to leverage the C# language to build DSL's/Fluent Interfaces. He walked the group through the various type of DSL's and how each one can be created and used. He did a nice job of backing up each of the DSL types with pretty simple and easy to follow examples. By the end of the session the group really was getting into the why of DSL's and how they can be beneficial to your team.

Planning the Openspaces

The kickoff to any openspaces conference it the planning session. Kaizen was kicked off with a bang, Scott Bellware and Doc (sorry do not know his last name) did a great job of setting up the rules of the conference and then leading us to a great planning session. What was really cool is that the majority of the sessions proposed where non-technical in nature (meaning there were only a few 'how do I use XYZ technology).

The reason I am happy about the lack of technical sessions proposed is because the majority of the sessions are on lean, Kanban and general improvement topics. And since this is a Continuous Improvement in Software Development Conference, this is exactly what I was looking for.

I am looking forward to today's sessions and am plan on learning how I can help to bring awareness and change to my organization.

Post Planning Beers

Some would say that this type of conference is really about the social interactions outside the actual conference. Typically I would agree with this and tonight was no difference. After the planning session a few of us headed back to the hotel bar to have few drinks and great conversation.

What really set this 'beers and chat' session apart from many others is that the Tom and Mary Poppendieck joined us (if you do NOT know who they are you really need to read their books). It was awesome to be able to pick their brains and gather years worth of insight. If you just sit back and listen to what they have to say you would be amazed with the amount of experience and insight they have and how they are both able to convey there experiences in a clear and concise manor.

Another really great thing is that I am able to meet some people that I have been interacting with (via twitter, IM, etc) for many months. It it always nice to be able to put a face to a name/twitter handle.

Looking forward to what todays sessions bring..... stay tuned it should be good.

Till next time,

.Net gets a new logo and I like it

Derik Whittaker — Mon, 27 Oct 2008 11:56:52 GMT

It turns out the team over in Redmond has decided that the .Net logo needed a little sprucing up. They have put together a pretty slick new logo and it was unveiled at the PDC. The new logo will be referred to as the Wave.

Here are a few links that talk about the new logo.

Till next time,

How is interacting with your data repository in your controller 'Different' or 'Better' than doing it in your code behind?

Derik Whittaker — Wed, 22 Oct 2008 12:03:04 GMT

Today I was looking through a sample Asp.Net MVC application and the first thing I noticed is that one of the controllers had 4 repositories injected into the controller (hey, at least they are injected right :) ). The code then went onto to interact with the various repositories in each of the various controller actions. In one case a controller chatted with a single repository 5 times.....:(

My question is this. How is having the controller chat with a repository different than having your code behind do so?

To me this is just NOT good. In my opinion the controller should only interact with either services (if you buy into that design pattern) or other business layer objects. I like the idea that my controller actions are skinny (thanks for that term Chris) and contain very little 'logic'. My fear with MVC is that controller actions will turn into the click events we have today with WebForms.

Am I off base? Thoughts... Comments.... Lets Debate this

Till next time,