维护站点类别的最佳实践
我正在构建一个 Web 应用程序,它使用外部构建的类来处理网站的大部分工作和规则。 大多数页面需要访问此类才能获取需要显示的信息。 过去,我会将这样的类放入会话变量中,以便在需要时可以轻松访问它,而不需要不断地重新实例化。
第一个问题,将此类填充到会话变量中(它不是很大)是一个坏主意吗?
第二个问题,如果将站点应用程序层类存储在会话中不是一个坏主意,那么有没有一种方法可以编写一个集中方法来用于获取类或将类存储到会话中? 我不想在获取类的页面之后使用一堆重复的代码页,检查它是否存在,如果不存在则创建等等。
I am building a web application which uses an externally built class to handle much of the work and rules for the site. Most pages will require access to this class to get the information it needs to display. In the past I would put such a class in a session variable, so it's easily accessible when required and not need to be continually re-instantiated.
First Question, is this a bad idea to stuff this class into a session variable (it's not very big)?
Second question, if it's not a bad idea to store the sites app layer class in a session, then is there a way I can write a centralized method to use to grab or store the class into the session? I don't want to use a bunch of repeated code page after page getting the class, checking its there, creating if it's not, etc.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
在决定在哪里存储您的类之前,您必须回答两个问题:
回答这两个问题的示例:请求、用户会话、应用程序。
如果这个类是无状态的(没有数据,只有逻辑),那么它可能可以在
应用的整个生命周期。 如果这只是每个用户独有的数据(不应在每个请求上重新加载),那么您可以将其直接放入会话中并跳过以下段落。
现在,在你决定了寿命之后,你就有了几种解决方案。 生活方式管理的最佳解决方案是 IoC 容器。 更简单的解决方案是抽象存储并使用静态外观,例如 Current.MyClass,其中 MyClass 实例存储在请求、会话或应用程序中,具体取决于向 Current 提供的存储。
但是,您不应该在指定的类中实现单例,因为它本身不应该决定您需要多少个实例,并且它限制了您在需要时用具有相同接口的另一个类替换它的能力。
Before deciding on where to store your class, you have to answer two questions:
Examples that answer both questions: request, user session, application.
If this class is stateless (no data and only logic), then it can probably live during the
whole life of application. If this is just data unique to each user (that should not be reloaded on each request), then you can put it directly into session and skip following paragraphs.
Now, after you decided on life length, you have several solutions. The best solution for lifestyle management is an IoC container. The simpler solution is just to abstract storage and use a static facade, like Current.MyClass, where MyClass instance is stored in request, session or application depending on what storage was provided to Current.
You should not implement singleton in the specified class, however, since it should not itself decide how many instances you need and it limits your ability to replace is with another class with same interface if required.
在不知道您使用的任何框架的情况下,将类放入会话存储中似乎不是明智之举 - 每个用户都会将其复制一次 - 除非它具有该用户独有的数据。
我能给出的最好建议是拥有一个单例类(你可以在谷歌上搜索它 - 这是一种设计模式),然后在该类中拥有一个函数,该函数将返回你需要的类,或者如果不需要则创建它但仍然存在。
Without knowing any frameworks you use, it does not seem smart idea to put a class into the session store - it will be copied once per user - unless it has data that is unique to that user.
The best advice I can give would be to have a singleton class (you can google it - it is a design pattern) and then just have a function in that class that will return the class you need, or create it if it doesn't yet exist.
对于是否应该首先将类存储在会话中,目前还没有定论。 通过我提出问题的应用程序,我选择不将课程塞入会话中,这确实没有必要,我很懒。 制定这种管理会话的方法一直都是值得的,因为这在 Web 开发中已经困扰我一段时间了。
我的研究结果是编写一个静态类来管理我的会话变量。 这个类处理会话的所有读取和写入,并将它们全部保持强类型以供我启动。 到处使用重复的代码来处理会话垃圾一直困扰着我。 也减少了拼写错误。
我在这方面找到了两篇我喜欢的文章,我现在只能找到其中一篇,当我找到它时,我会包含另一篇。
第一个位于 代码项目
这可能是第二个 链接
该模式简单而直接。 我还构建了一个用于从 url 查询字符串中获取参数的请求类。 我认为没有理由不将其扩展到 cookie。
这是我第一次使用该模式,我只使用字符串,因此私有方法有点受限,但可以轻松更改为使用任何类或原始类型。
The jury is still out on if the class should be stored in the session in the first place. With the app I asked the question for, I opted on NOT stuffing the class into session, it really wasn't necessary, I was being lazy. Working out this method to manage the session was worth all the time, as it's something that has bothered me for some time in web development.
What came out of my research is writing a static class to manage my session variables. This class handles all reads and writes to the session and keeps them all strongly typed for me to boot. It has always bothered me using repeated code all over the place for session crap. Keeps typos way down too.
There are two articles I like which I found on this, I can only locate one of them now and will include the other when I locate it.
The first was at Code Project
This may be the second link
The pattern is easy and straight forward. I have also built a class for requests for grabbing parameters from url query strings. I see no reason not to extend it to cookies too.
This was my first use of the pattern, I only used strings so the private method is a bit limited, but this can easily be changed to use any class or primitive type.