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?
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; }}
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?
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 [:(]
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.
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 [:)]
ChadThiele
Participant
983 Points
274 Posts
Pass More Than One Strongly Typed ViewData Object?
Dec 23, 2007 02:40 AM|LINK
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.
abombss
Member
575 Points
164 Posts
Re: Pass More Than One Strongly Typed ViewData Object?
Dec 23, 2007 03:06 AM|LINK
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}); }sergiopereir...
Member
227 Points
61 Posts
Re: Pass More Than One Strongly Typed ViewData Object?
Dec 23, 2007 03:09 AM|LINK
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
Sergio Pereira
http://devlicio.us/blogs/sergio_pereira/
tgmdbm
Contributor
4392 Points
883 Posts
ASPInsiders
MVP
Re: Pass More Than One Strongly Typed ViewData Object?
Dec 23, 2007 03:13 AM|LINK
The simplest way is to create a small class which has properties for each object you want to pass to the view.
abombss
Member
575 Points
164 Posts
Re: Pass More Than One Strongly Typed ViewData Object?
Dec 23, 2007 03:14 AM|LINK
[Nope]
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.
[666]
abombss
Member
575 Points
164 Posts
Re: Pass More Than One Strongly Typed ViewData Object?
Dec 23, 2007 03:19 AM|LINK
I would suggest only to make those virtual so you can mock the View and test it or use R# to generate an interface.
sergiopereir...
Member
227 Points
61 Posts
Re: Pass More Than One Strongly Typed ViewData Object?
Dec 23, 2007 03:00 PM|LINK
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?
Sergio Pereira
http://devlicio.us/blogs/sergio_pereira/
abombss
Member
575 Points
164 Posts
Re: Pass More Than One Strongly Typed ViewData Object?
Dec 23, 2007 07:05 PM|LINK
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?
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 [:(]
sergiopereir...
Member
227 Points
61 Posts
Re: Pass More Than One Strongly Typed ViewData Object?
Dec 23, 2007 09:26 PM|LINK
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.
I think you may be over-simplifying a practice that I didn't even promote. What I said was simply
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.
Sergio Pereira
http://devlicio.us/blogs/sergio_pereira/
abombss
Member
575 Points
164 Posts
Is Code-Behind Evil?
Dec 23, 2007 10:15 PM|LINK
But its interesting... And the OP got his problem solved.
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. 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 [:)]