如何从 Web 应用程序层下面的层访问 Session 值

发布于 2024-08-30 05:56:23 字数 313 浏览 8 评论 0原文

我们的应用程序中有许多实例,我们希望能够访问业务域和数据访问层中当前登录的用户 ID 等内容。在日志中,我们将此信息推送到会话,因此我们所有的前端代码当然都可以相当轻松地访问它。然而,我们在获取应用程序较低层的数据时遇到了巨大的问题。我们似乎找不到一种方法来在业务域中存储仅供用户使用的全局范围的值(静态类和属性当然由应用程序域共享,这意味着会话中的所有用户只共享一个对象的副本)。我们考虑过将会话传递给我们的业务类,但是我们的域与我们的 Web 应用程序紧密耦合。我们希望保持该应用程序的 winforms 版本的前景。

我很难相信我们是第一批遇到此类问题的人。您在应用程序中如何处理这个问题?

We have many instances in our application where we would like to be able to access things like the currently logged in user id in our business domain and data access layer. On log we push this information to the session, so all of our front end code has access to it fairly easily of course. However, we are having huge issues getting at the data in lower layers of our application. We just can't seem to find a way to store a value in the business domain that has global scope just for the user (static classes and properties are of course shared by the application domain, which means all users in the session share just one copy of the object). We have considered passing in the session to our business classes, but then our domain is very tightly coupled to our web application. We want to keep the prospect of a winforms version of the application possible going forward.

I find it hard to believe we are the first people to have this sort of issue. How are you handling this problem in your applications?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

⊕婉儿 2024-09-06 05:56:23

我认为让您的业务类依赖于全局对象并不是一个好主意,并且如果可能的话会避免它。您应该向它们注入必要的信息 - 这使得它们更具可测试性和可扩展性。

因此,您应该将所需的信息访问方法包装到存储库类中,而不是将 Session 对象直接传递给它们。您的业​​务层可以使用存储库类作为数据源(例如,对其调用 GetUser()),并且您的 Web 应用程序的存储库可以使用会话来检索请求的信息(返回 >_session.User.Identity)。

将其移植到 winforms 时,只需使用新的以 winform 为中心的类实现存储库接口(即 GetUser() 返回用户主体的 Windows 版本)。

I don't think having your business classes rely on a global object is that great of an idea, and would avoid it if possible. You should be injecting the necessary information into them - this makes them much more testable and scalable.

So rather than passing a Session object directly to them, you should wrap up the information access methods that you need into a repository class. Your business layer can use the repository class as a data source (call GetUser() on it, for example), and the repository for your web app can use session to retrieve the requested information (return _session.User.Identity).

When porting it to winforms, simply implement the repository interface with a new winform-centric class (i.e. GetUser() returns the windows version of the user principal).

ペ泪落弦音 2024-09-06 05:56:23

我完全同意 Womp - 将数据从前端注入到较低层。

如果你想做一个半途而废的作弊(但不是太多的作弊),你可以做的是创建一个非常小的程序集,只有几个 POCO 类 用于存储您想要在所有层之间共享的所有信息(当前登录的用户名、登录时间等),并且只需从您的前端进入您的业务/数据层。现在,如果你这样做,你必须避免将这个 POCO 程序集变成通用程序集的诱惑 - 它必须保持很小,否则你将来会遇到问题(相信我,或者学习困难的方法,或者请其他人详细说明这一点)一)。然而,如果您有这个 POCO 程序集,通过各个层注入这些数据就变得非常容易,而且由于它是 POCO,它的序列化效果非常好,并且可以很好地与 Web 服务、WCF 等配合使用。

I agree with Womp completely - inject the data down from your front-end into your lower tiers.

If you want to do a half-way cheat (but not too much of a cheat), what you can do is create a very small assembly with just a couple POCO classes to store all of this information you want to share across all of your tiers (currently logged-in username, time logged in, etc.) and just pass this object from your front-end into your biz/data tiers. Now if you do this, you MUST avoid the temptation to turn this POCO assembly into a general utility assembly - it MUST stay small or you WILL have problems in the future (trust me or learn the hard way or ask somebody else to elaborate on this one). However, if you have this POCO assembly, injecting this data through the various tiers becomes very easy and since it's POCO, it serializes very well and works nicely with web services, WCF, etc.

擦肩而过的背影 2024-09-06 05:56:23

理论上,人们会告诉你这是一种糟糕的商业行为。
在实践中,我们只需要业务层始终可用的会话级别的数据。 :-(

我们最终将不同的存储引擎统一在一个小接口下。

public interface ISessionStorage 
{
   SomeSessionData Data {get;set;}
   ...
   .. and most of the data we need stored at "session" level
    }
 //and a singleton to access it
    public static ISessionStorage ISessionStorage;

这个接口几乎可以从我们代码中的任何地方使用。

然后我们就有一个 Session 和/或一个单例实现

 public WebSessionStorage
{
   public SomeSessionData Data 
  {
       get { return HttpContext.Current.Session["somekey"] as SomeSessionData;}
      set { HttpContext.Current.Session["somekey"] = value;}
  }

public WebFormsSessionStorage
{
   private static SomeSessionData  _SomeSessionData; //this was before automatic get;set;
   public SomeSessionData 
   {
       get{ return _SomeSessionData;}
       set{ _SomeSessionData=value; }
}

}

在初始化应用程序时,网站将执行

 Framework.Storage.SessionStorage = new WebSessionStorage(); 

在 Global.asax 中,FormsApp 就可以

 Framework.Storage.SessionStorage = new WebFormsSessionStorage(); 

In theory people will tell you it's a bad business practice.
In practice, we just needed the data from the session level available in the business layers all the time. :-(

We ended up having different storage engines united under a small interface.

public interface ISessionStorage 
{
   SomeSessionData Data {get;set;}
   ...
   .. and most of the data we need stored at "session" level
    }
 //and a singleton to access it
    public static ISessionStorage ISessionStorage;

this interface is available from almost anywhere in our code.

Then we have both a Session and/or a singleton implementation

 public WebSessionStorage
{
   public SomeSessionData Data 
  {
       get { return HttpContext.Current.Session["somekey"] as SomeSessionData;}
      set { HttpContext.Current.Session["somekey"] = value;}
  }

public WebFormsSessionStorage
{
   private static SomeSessionData  _SomeSessionData; //this was before automatic get;set;
   public SomeSessionData 
   {
       get{ return _SomeSessionData;}
       set{ _SomeSessionData=value; }
}

}

On initing the application, the website will do a

 Framework.Storage.SessionStorage = new WebSessionStorage(); 

in Global.asax, and the FormsApp will do

 Framework.Storage.SessionStorage = new WebFormsSessionStorage(); 
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文