Where to store feedback UI data in ASP.NET MVC 2?

I'm really new to both ASP.NET MVC and the MVC pattern generally.

For context, I'm currently running .NET 4.0, MVC 2.

I know that MCV 2 has a bunch of built in features for:

• validation (both client and server side, through a variety of ways)

• error handling (via attributes and other methods)

But what should be used to return feedback to the user that is neither an error nor validation?

For example, I have a simple form that returns a csv (using myController.base.file()) IF data is found.

If data is not found, I'd like to return the View with the Model as-is plus a message, like, "no data found,开发者_Python百科 try a different date range"

Now,

should that kind of feedback message be stored in the model itself?, or

is there a cleaner mechanism for this?

Is that what the ModelStateDictionary is for?

UPDATE

just to clarify. I know there may be many ways to do what I want, but what's the correct MVC way of doing it.

Keep in mind the feedback data is not an error, and I don't want to redirect to some other view.

---

I think what might clear the air is the idea of a ViewModel. Except for the most simple scenarios, you'll find more than one kind of model in your project. They can go by many names, but I find these names helpful:

Pure domain models (Models)
This is where you have your ideal representations of our data model.

Application models (ViewModels)
These models account for the realities of displaying your domain model in a view. They contain data specifically needed for a specific view. It's perfectly acceptable to put something like a status message in this kind of a model.

I would recommend this insightful blog post which shows when, why and how to use ViewModels.

Example:

public class WidgetDataExportViewModel {
  public DateTime StartDate {get;set;}
  public DateTime EndDate {get;set;}
  public MyEnum SomeOtherProperty {get;set;}
  public string StatusMessage {get;set;}
  public IEnumerable<Widget> Widgets {get;set;}

}

---

If you're talking about a message that you want to code for somewhere in your view, you ought to have that on your model and have your view consume it.

If you want to be able to handle system messages generally in the same way across your application (with a message at the top or side of the window, e.g.), you might create a utility method that puts the information in ViewData with a special key that could get picked up by your master page. If you use TempData instead, the message could be persisted across a redirect.

---

I have previously used ModelState.AddModelError successfuly to show a summary message. Just make sure you use a key that is not a Model field name.

Note: I have adapted my design from Steven Sanderson's book (see the index on RulesException)

Good luck

---

Validation errors directly stemming from user actions on your model (e.g. too short a password)
is at home as close to the model as possible.

General error messages of the "no data found" kind are easier addressed through having a dedicated Error View of some sort.

---

Added:

If I understand you correct, you prefer to stick with one view; be it validation gold or burning SQL servers ;-)

Not madly MVC2 experienced mysef, but being consistent and always create own models, never what you might be served by what(not) ORM you're using (Linq<->SQL, EF) should give you the fine-graininess you need.

If my memory serves me correct I think the Nerddinner could be enlightening; and if you really
want to take the plunge, why don't go Deep Inside ASP.NET MVC 2 Model Metadata and Validation

---

I've gotten my MVC mainly from books, but the blogosphere has definitely started producing golden material on the more "foreign" parts of ASP.NET MVC.
My real aha moment regarding the M of MVC came while reading
Steve Michelotti's ASP.NET MVC View Model Patterns (a great source for MVC2 info all round)