I know, it doesn't seem to make sense... but I was wondering if it's possible to pass more than one strongly typed object to the ViewData?

My dilemma is this:
I'm creating a calculator that also displays user data. The user data is stored in the database and pulled when someone visits a url that looks like: www.site.com/name. Inside the database are some values that get pulled and then calculated. I've developed an object to hold the calculation results. I've now got a user object and a calculation results object I'd like to pass to the view for rendering. Short of merging the two objects, is there a way to handle this strongly typed?

Thank you in advance.


 

Typically for views I create actual view objects.  This also makes testing a little easier.

In Monorail I only have to create an interface and use the DictionaryAdapter which wraps my interface around the ViewData so I get a strongly typed view.

With simple properties in 3.5 and object initializes I would stick to this methodology only using classes instead of interfaces.  So in your scenario you would create a composite view object for what you actually need.

 

public class CalculatorView
{
  public virtual User User { get; set; }
  public virtual CalculatorResult { get; set; }
}

// Then to set your view data

public void Calculate(int x, int y)
{
  CalculatorResult result = calculator.Calculate(x, y);
  User user = MySession.CurrentUser;
  RenderView("Calculate", new CalculatorView{ User = user, CalculatorResult = result});
}

  

You can create a class that holds a reference to each of these objects, like two properties, but I guess you may be looking for a more flexible approach. In this case I'd not use a typed view and just pass the objects in regular ViewData["user"], ViewData["calculation"]. To make your ASPX file a little cleaner you could add properties to the code-behind to typecast the ViewData items:

public UserClass TheUser{ get {return ViewData["user"]  as UserClass; }}

You get the idea...

  - sp
 

 

The simplest way is to create a small class which has properties for each object you want to pass to the view. 

public class ActionViewData
{
  public User User { get; set; }
  public CalcuationResults CalcuationResults { get; set; }
}

sergiopereira:

To make your ASPX file a little cleaner you could add properties to the code-behind to typecast the ViewData items:

 

Code behind is evil and MS shouldn't even generate a stub file for it in MVC.  It is going to lead to some crazy things.

 

tgmdbm:

public class ActionViewData { public User User { get; set; } public CalcuationResults CalcuationResults { get; set; } }

 

I would suggest only to make those virtual so you can mock the View and test it or use R# to generate an interface.

abombss:

Code behind is evil and MS shouldn't even generate a stub file for it in MVC.  It is going to lead to some crazy things.

 

I'll have to disagree with that. Code behind is part of the UI. As long as you're using it for UI chores, there's nothing evil about it. Avoiding the code behind at all costs will lead to ridiculously spaghettastic ASPX files.

 You can put business logic in your SQL statements or stored procedures, but do you? Does that make stored procedures evil?

 

 

 

sergiopereira:

You can put business logic in your SQL statements or stored procedures, but do you? Does that make stored procedures evil?

 

Yes, sprocs are evil, that is why on the 8th day we got ORM's.  I can't tell you the last time I walked into a client didn't find the majority of the application written in sprocs, business logic and all.  Webforms promotes that sort of Data Driven architecture.  Create the database, generate some sprocs, wire up some grid views, and wolla, you have a working application.

Poll: Do you start designing your application from database, the domain/model, or the view? 

sergiopereira:

Avoiding the code behind at all costs will lead to ridiculously spaghettastic ASPX files.

 

I understand given the architecture of the framework and that asp.net and c# are not the greatest template engines and you might need some code behind.  But I also consider this to be an edge case, In my apps I am only going to use code behind on base pages.  If I have to use code behind on regular views I am probably doing something wrong.  Just my opinion.

I think promoting code behind is just bad practice, especially for those coming from webforms new to mvc.  How do you test your code back their?

The biggest thing I realize after writing some ugly views is... I miss Brail 

abombss:

Yes, sprocs are evil, that is why on the 8th day we got ORM's.

 

We are going way off-topic here, but your idea of evil is not the same as mine. If you consider something evil because it was used to do harm, then we cannot have a fair discussion here. For me, evil is not in the things but in how things are used. 

abombss:

I think promoting code behind is just bad practice

 

I think you may be over-simplifying a practice that I didn't even promote. What I said was simply 

sergiopereira:

As long as you're using it for UI chores, there's nothing evil about it.

 

So, just like you, I also think that adding business logic to the code-behind is bad-practice, but I'm completely fine with myRepeater.DataBind() in the code-behind. 

But hey, whatever, it's almost a personal choice anyway. 

sergiopereira:

We are going way off-topic here

But its interesting... And the OP got his problem solved.

sergiopereira:

For me, evil is not in the things but in how things are used. 

I agree, but I still keep my position that these things are evil because it is too easy to misuse them given the default tools developers have.  We should be promoting tools and frameworks that making doing the "right thing" easier instead of doing the wrong thing.  Feel free to flame me on the "right thing", its pretty subjective and it certainly depends on the context of the problem.

sergiopereira:

but I'm completely fine with myRepeater.DataBind() in the code-behind. 

I am not sure what the solution is, but that is not it.  I don't think that has any business in the view.  Its a bad hack to resuse webforms controls.  Controls, as they are defined by webforms have no business in ms mvc.

 

So I think we are almost in agreement... Its running with scissors

It's always about those darn scissors, isn't it? Let's leave this at the almost :) 

Thanks all, can't believe I didn't think of it, but thank you!