我应该在哪里保存复杂的MVC应用程序UI状态? [英] where should I save a complex MVC application UI state?
问题描述
我一直在研究几个MVC框架(例如rails，merb，cakephp，codeignitier以及类似的东西...)
我见过的所有示例基本上都是简单的CRUD页面，在查询字符串和发布的字段值中包含所有infr.
我有一些应用程序是用经典的ASP构建的某种框架制作的.
此框架处理的一些CRUD内容比我发现的示例要复杂一些.
例如主从细节，示例过滤，分页，排序和类似内容.
我有一个控制器类，它只是一个有限状态机，它经过不同的状态(例如新建，浏览，过滤，显示等)，然后根据引发的事件执行适当的操作，最后检索需要信息到呼叫页面.
要实现这一点，我有几个隐藏的输入来保持网页状态(例如当前ID，过滤条件，订单条件，先前状态，先前事件，好了，您知道了)
您认为实现这种功能的最好方法是什么?
隐藏在视图中并由控制器使用的隐藏输入? (我想那相当于我现在在classi asp中所做的事情)-
(为响应tvanfosson而添加)
基本上，我的问题是针对第三类，即上下文相关的设置(就我同意的其他两个类别而言)，我存储在隐藏字段中以将其存储在查询字符串中的信息，我猜想是什么时候您单击下一页"，将需要保存的所有内容都包含在查询字符串中，对吗?这样，该查询字符串就会附加到执行某种操作的每个链接中.
我不确定，使用querystring而不是隐藏的输入有什么优缺点?
我根据实际数据的特征使用不同的策略.作为首选项的东西，例如默认页面大小，我保存在与当前登录用户关联的首选项"对象(表)中，并在需要时从那里进行检索.
与当前登录相关的持久性设置(例如页面的过滤器设置)存储在用户的会话中.通常，如果用户在当前会话中对其进行设置，则这些东西应该保持粘性.我认为过滤器设置和可见性是这样的.如果我过滤列表，请从列表中导航至某个特定项目，然后返回列表，我希望重新应用我的过滤器设置-因此我将其作为会话的一部分.
上下文相关的设置-如当前的排序列或页码，是使用查询参数控制的.使用适当的查询参数构建分页和排序控件(链接)，以在单击时做正确的事"，并传递任何必要的查询参数以维护或更新控件的当前上下文.使用查询参数使您可以使用可添加书签的HTTP GET，而不是POST.使用隐藏的表单参数使用户更难以保存或输入将其直接带到他们想去的位置的URL.对于分页而言，这可能比分页更有用，但该原理同样适用.
I've been having a look at several MVC frameworks (like rails, merb, cakephp, codeignitier, and similars...)
All the samples I've seen are basically plain and simple CRUD pages, carrying all the infr needed in the querystring and the posted field values.
I've got a couple of apps made with some sort of framework built with classic asp.
This framework handles some CRUD stuff a little more complex than the examples I found.
Something like master-detail, filtering by example, paging, sorting and similars.
I have a controller class that it's just a finite state machine, that goes thru diferent states (like new, browse, filter, show, etc.), then performs the appropiate action depending on the event raised and finally retrieves the neede info to the calling page.
To achieve this I have several hidden inputs to keep the state of the web page (like current id, filter criterias, order criterias, previous state, previous event, well, you get the idea)
What do you think would be the finnest approach to achieve this kind of funcionality?
hidden inputs built in the view and used from the controller??? (I guess that would be the equivalent of what I'm doing right now in classi asp)
--
(added in response to tvanfosson)
basically, my question refers to the third category, the context-dependent setting (in respect to the other two categories I agree with you) the info I was storing in hidden fields to store them on the querystring, I guess that when you click on the "next page" you include everything you need to save in the querystring, right? so that piece of query string gets appended in each and every link that performns some kind of action...
I'm not sure, what are the advantages and disadvantages of using the querystring instead of hidden inputs???
I use different strategies depending on the character of the actual data. Things that are preferences, like default page size, I keep in a Preferences object (table) that is associated with the current logged in user and retrieve from there when needed.
Persistent settings associated with the current logon, like filter settings for a page, are stored in the user's session. Generally these are things that if a user sets them in the current session they should remain sticky. I think filter settings and visibility are like this. If I filter a list, navigate away from it to drill down into a particular item, then come back to the list, I want my filter settings to be reapplied -- so I make it part of the session.
Context-dependent settings -- like the current sort column or page number, are controlled using query parameters. Paging and sort controls (links) are built with the appropriate query parameters to "do the right thing" when clicked and pass any necessary query parameters to maintain or update the current context of the control. Using the query parameters allows you to use an HTTP GET, which is bookmarkable, rather than a POST. Using hidden form parameters makes it much harder for the user to save or enter a URL that takes them directly where they want to go. This is probably more useful for sorting than it is for paging, but the principle applies equally.
这篇关于我应该在哪里保存复杂的MVC应用程序UI状态?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
