/aspnet-mvc-gotcha-string-model#comment-17@Ashic: I see your point now; your response really cleared it up for me. Thanks.2011-04-20T07:19:16urn:comment:17/aspnet-mvc-gotcha-string-model#comment-16@Jesse: Yes, you could definitely pass the string in ViewBag. But you could also pass anything on god's green earth in ViewBag. The point is expected "normal" behaviour. The controller is expected to pass the model to the view. Passing the master / layout is in general an exceptional situation. As such, I would expect the most intuitive syntax to display the expected common behaviour. In this case, it does not. You have to be aware that .NET is using the type of the second parameter to resolve the overload that's called. A much simpler solution would be to have View(viewName, model) and View(viewName, model, master) overloads rather than the master coming second. [Ideally, I'd prefer it if the master weren't at all present in the overload. Specifying the master so easily encourages controller logic encroaching beyond its boundaries.]2011-04-19T13:35:05urn:comment:16/aspnet-mvc-gotcha-string-model#comment-15You mention that the master/layout could just as easily be added to ViewBag. I would argue that if your model is just a string, you could just as easily use ViewBag.2011-04-19T08:01:42urn:comment:15/aspnet-mvc-gotcha-string-model#comment-14Another solution would be casting it to an object: [quote] string model = "my sample string model"; return View("Index", model as object); [/quote] Then it would match the overload you wanted.2011-04-19T01:07:02urn:comment:14/ViewBag-can-be-goode280a6honestly#comment-25I have to agree. Sometimes it is better just to be pragmatic, rather than a perfectionist.2011-04-05T03:07:23urn:comment:25/ViewBag-can-be-goode280a6honestly#comment-24My bad...I thought you were talking about a page that displayed both the entire "Create" form *and* the grid containing existing entries. For the button only, yeah, I can definitely see putting the ID into the ViewBag. 2011-03-17T06:08:01urn:comment:24/ViewBag-can-be-goode280a6honestly#comment-23That's just my point - all I want is a button that would show the create view. For that, all I need is that the MemberId is passes to the view somehow. With your approach, the extra partial would have a single button, I would need another viewmodel class, have to test all of that in isolation and STILL would have to UI test everything to make sure it works properly. Passing the MemberId in the viewbag means I don't need an extra partial, I don't need an extra viewmodel class, I can test whether the MemberId is passed to the view from the controller in a single unit test and have the SAME UI test to ensure it works properly. The benefit is fewer dumb DTO classes, fewer unit tests for the controller, removal of a quite unreusable partial. The con is loss of intellisense. You're not losing testability one bit but your reducing the amount of boilerplate code. Hence I prefer the viewbag to pass in additional data.2011-03-16T00:33:53urn:comment:23/ViewBag-can-be-goode280a6honestly#comment-22I guess I'm still not clear on why you wouldn't separate the two into partials that are tested in isolation then rendered in a single page as needed...but hey, whatever works for you!2011-03-15T18:49:04urn:comment:22/ViewBag-can-be-goode280a6honestly#comment-21@Gregg, simple...say this page has a "Add New Address" button AND a list of existing addresses. For this page, I WOULD pass in IEnumerable<MemberAddressViewModel> as the model. But for the "Add New Address" button, I'd need a MemberId. I can't depend on the passed in collection as a source of the MemberId as the collection might be empty. Some people would create an aggregated viewmodel like: MemberIndexViewModel - MemberId - IEnumerable<MemberAddressViewModel> I'm arguing that that's a waste and simply passing MemberId in ViewBag is a more pragmatic solution. As for testability, a single unit test can verify whether or not the MemberId is being set - which you'd have anyway even with the aggregated viewmodel.2011-03-14T13:39:43urn:comment:21/ViewBag-can-be-goode280a6honestly#comment-20Okay, maybe I'm missing something but why would you not use a special view model like this... /* - - - - - - - - - - */ MemberAddressViewModel - MemberId - MemberAddressLine1 - MemberAddressLine2 - MemberCity - MemberState - MemberCountry - MemberZipCode /* - - - - - - - - - - */ ...let the view reference IEnumerable<MemberAddressViewModel> as it's model, and then use a tool like AutoMapper (available via Codeplex and NuGet) to handle the mapping to/from your view-specific model and your actual underlying base models? 2011-03-14T12:24:43urn:comment:20/ninja-coding-code-comments#comment-32Yup...clean code is a must read regardless of programming language used. As for stale "coded comments" - you do need to be careful. Refactoring doesn't stop when you've got back previous functionality - it should go on to remove dead code and rename stuff to ensure the acurate "current" language is being conveyed. Without that, refactoring won't be complete and you'll end up with many methods that aren't ever used. (Tools like nDepend can help in identifying dead code.) Having coded comments encourages more frequent updates than pure comments and makes it easier to change. A positive side effect is that you're forced to keep things small and the tendency for god classes and methods seem to go down the more you practice it.2011-01-12T09:07:47urn:comment:32/ninja-coding-code-comments#comment-31Great article. I don't know if you have read it but Clean Code by Robert Martin really drives this coding style home and puts a very detailed case up for it. I have largely stopped commenting my code now, opting instead for longer names that convey intent and splitting code into many small functions. One thing I have found with this technique is that it doesn't completely solve the issue of stale comments. When your function names become the "comments" you just push the problem back another level. Incremental changes to a function can eventually result in your chosen function name going stale. It doesn't solve the problem but it certainly reduces it so its something I have stuck with.2011-01-12T05:18:42urn:comment:31/ninja-coding-code-comments#comment-30@jlm...think you might be missing the point slightly. The guy you mentioned - multi thousand lines of zero comment code - his code is not self explanatory. He has to dig deep in order to find out what's going on. And him digging through thousands of lines suggests a high probability of God classes - and even if not that then definitely a lack of cohesion. Even if he had some "meaningful" comments, you'd still see him sifting through thousands of lines of code (and some added comments as well). It is very rare (I won't say non-existant though) that a "simple" comment can convey so much understanding that cannot be achieved through simple refactorings.2010-12-27T09:46:15urn:comment:30/ninja-coding-code-comments#comment-29I worked with a guy before who would say:"I read code, I don't need comments.". He probably considered himself "ninja coding". He would spend hours scrolling up and down through his multi-thousand line zero-comment "dostuff" method trying to make very minor changes. A few simple comments documenting what he was doing would have gone a long way. This is an extreme example, much like the one in your article. Finding the best balance between worthless comments and true useful ones is the real "ninja coding"...unfortunately the bad coders like the one I mentioned will breeze through this article and use it as justification for their zero-comment style.2010-12-26T05:59:01urn:comment:29/aspnet-routing-iis7-remember-modules#comment-38Thanks! This solved my problem with getting routing to work on an old website project. I have been googling this since last night :)2010-09-30T02:39:28urn:comment:38/aspnet-mvc-3-ctp1-view-improvements#comment-35genius. Please keep on the innovation.2010-09-28T16:32:56urn:comment:35/aspnet-mvc-3-ctp1-view-improvements#comment-34Great video and many more features available in mvc 3.02010-09-27T01:10:22urn:comment:34/ASPNET-MVC-Unit-Testing-JsonResult-Returning-Anonymous-Types#comment-48This is a great article, thank you! I personally liked n.2 approach, using mocks.. Trying to remember that techique :)2010-09-23T03:20:42urn:comment:48/exposing-wcf-ajax-silverlight#comment-73Hi Carlos...sorry for the delay. Your post wasn't deleted...I moderate comments since I get batchfulls of spam every week. Your question is definitely valid. The answer to it is that the example in the url is showing off how to create a WCF service. It shows a two tier solution with Smart UI (in this case, since the service is what communicates with the outside world, it can be deemed the UI). Two tier solutions are perfectly valid for many scenarios. It's comparable to how most WebForms applications are made - with code and logic in the UI layer. Putting logic in the code behind of WebForms pages is comparable to putting logic in the WCF service. It might be ok for simple situations, but for complicated business logic, it's best done separately. That ensure your business logic is not muddied by presentation specific code and annotations and is kept maintainable and reusable.2010-09-11T05:31:02urn:comment:73/exposing-wcf-ajax-silverlight#comment-72hmm did my other post got deleted with the url? It was an honest question as i am trying to brake into wcf and jquery.2010-09-11T02:05:17urn:comment:72