Global vars in different build scenarios.

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Adrian

    Global vars in different build scenarios.

    We have a solution where one project contains a set of business rules. We
    use the rules in a web application and they're integrated into the main web
    project. Any global varaibles for the user are stored on the web session,
    and that all works fine.

    Now the fun part, we now have to be able to call these business rules from
    an old powerbuilder app, where a web server isn't available, so have to use
    a com interface layer to call the business rules. The problem is that we
    need the com class to initialise some variables and make them available to
    the rules class. I know there's not a session object, but how do you go
    about coding for the two very different scenarios that the business object
    will be living in?

    Cheers
    Adrian


  • Jeroen Mostert

    #2
    Re: Global vars in different build scenarios.

    Adrian wrote:
    We have a solution where one project contains a set of business rules. We
    use the rules in a web application and they're integrated into the main web
    project. Any global varaibles for the user are stored on the web session,
    and that all works fine.
    >
    Now the fun part, we now have to be able to call these business rules from
    an old powerbuilder app, where a web server isn't available, so have to use
    a com interface layer to call the business rules. The problem is that we
    need the com class to initialise some variables and make them available to
    the rules class. I know there's not a session object, but how do you go
    about coding for the two very different scenarios that the business object
    will be living in?
    >
    I don't know exactly who said it, but it's a truism that there's no problem
    in computing that can't be solved by adding an extra layer.

    Create a new assembly and within it define a UserGlobals class to hold the
    globals you need. Give it a static factory method to return the globals for
    a particular user. The business object should use that method only to get at
    the globals, and the only thing that's different is the way you
    create/initialize these instances. You can check HttpContext.Cur rent to see
    if you're running in the context of a website (you can reference System.Web
    from any .NET assembly, it doesn't need to be a website project). If so,
    retrieve settings from the session, if not, get them some other way.

    --
    J.

    Comment

    • Adrian

      #3
      Re: Global vars in different build scenarios.

      Aha ok thanks Jeroen

      "Jeroen Mostert" <jmostert@xs4al l.nlwrote in message
      news:48ecf63d$0 $189$e4fe514c@n ews.xs4all.nl.. .
      Adrian wrote:
      >We have a solution where one project contains a set of business rules.
      >We use the rules in a web application and they're integrated into the
      >main web project. Any global varaibles for the user are stored on the
      >web session, and that all works fine.
      >>
      >Now the fun part, we now have to be able to call these business rules
      >from an old powerbuilder app, where a web server isn't available, so have
      >to use a com interface layer to call the business rules. The problem is
      >that we need the com class to initialise some variables and make them
      >available to the rules class. I know there's not a session object, but
      >how do you go about coding for the two very different scenarios that the
      >business object will be living in?
      >>
      I don't know exactly who said it, but it's a truism that there's no
      problem in computing that can't be solved by adding an extra layer.
      >
      Create a new assembly and within it define a UserGlobals class to hold the
      globals you need. Give it a static factory method to return the globals
      for a particular user. The business object should use that method only to
      get at the globals, and the only thing that's different is the way you
      create/initialize these instances. You can check HttpContext.Cur rent to
      see if you're running in the context of a website (you can reference
      System.Web from any .NET assembly, it doesn't need to be a website
      project). If so, retrieve settings from the session, if not, get them some
      other way.
      >
      --
      J.

      Comment

      Working...