We Keep Coding

ASP.NET share same session with .aspx page in IFream

I have an MVC application, where one controller returns a View that have an iframe , controller also returns url that need to loaded.
I need that iframe to load legacy .aspx pages.
Now I want to share some data from MVC controller to that .aspx page via 'SESSION' or 'Request' object.
Is it possible ? Do I have any other alternative to share data securely (I don't want to pass as get parameters).

Since we are talking about two different applications, there are some options but none through SESSION
Your first issue is how to identify the same user. There are two options here.
Through the use of cookies, if both applications are in the same domain. You can store a session identifier there and it will be sent to both applications. A jwt token would do fine or any other session identifier
Through the use of a single sign on system. This would be more tricky to implement and there are a lot of oauth/openidconnect systems out there to choose from.
Now onto the session iteself. Since we are talking about two applications, you are going to need some kind of shared place to store the session values
The simplest form would be a shared database where you store the session values. It could be in memory tables in mssql to speed things up. On the downside, you should be careful to invalidate/update the values which would cost in queries
Some kind of distributed cache, like REDIS.
Warning - You might see suggestions to use session state store. This is to share SESSION between servers and not so easily between applications, so I wouldn't suggest that.

NHibernate Db Calls made in a web session

I have recently started working on a project using NHibernate as a ORM tool.I read about the contextual session in nHibernate and understood the idea behind it. I have a doubt in one area,
Let's say, i have a employee domain and in a http call,i am calling my repository for getting employee id =1 , 3 times.
Employee employee = _employeeRepository.GetEmployee(1);
Case 1: It will be a 1 db call
Case 2: It will be 3 db calls.
please guide me on this.
rgds
Sandy

It depends on your setup.
The first level cache will hit the DB once against each Session object you use to query with. If there is a single Session shared with this repository.. only one DB call will be made. However, if each call to the repository causes more than one Session to be created, you'll get multiple calls. This is the default.
If the second level cache is enabled, then each Session created via a SessionFactory will share the above properties. Meaning, if you have multiple repositories with multiple Session's that came from the same SessionFactory instance.. then loading the same employee from both repositories will cause a single DB call.
There is some good information in this post - it is related to Hibernate, but the basic principles still apply to NHibernate.
I would recommend you enable a second level cache (we use SysCache2) in a web environment.. so that you can guarantee that the Session's always share cached objects within a single request (assuming of course, that your Session lifetime management is per-request.. which is should be..).

Persist List of Objects Between Pages - ASP MVC

C# - ASP MVC - .NET 4.5 - Bootstrap - Razor
I have a form wizard (http://vadimg.com/twitter-bootstrap-wizard-example/examples/basic.html) that is used to setup a complex object (obj1). A property of obj1 is a List<obj2>. On one step of the wizard I want to add multiple obj2's to the list. Since obj2 is slightly complex as well, I thought I would use another wizard to help build it. Except I need to persist this List<obj2> on wizard 1, while I'm off in wizard 2 building another obj2.
My first thought was to use a session to hold the List<obj2>, I was just wondering if that's a good option, or if there would be a better one? The user may leave from Wizard1 to go to Wizard2 and come back multiple times.

There's no perfect answer here; each approach has trade-offs. But here are some options that I can think of (and these are independent of ASP.NET/C#)
Session (as you suggest)
This will store data in web server memory (by default). If you have a lot of users, this could be a problem.
You risk the information being lost when the user gets a new cookie/the session times out.
Potentially better performance that a db, depending again on the number of users
Database (as you mentioned)
Could cause more database traffic.
Can save information for user even if they close a browser, switch computer, the power goes out, etc.
Maybe a separate NoSQL database just for transient wizard data would be worth trying.
Cookie (store data on the user's computer)
Users can potentially tamper with/view the data
There is a limit on cookie size (4 KB each?)
Local storage (HTML5)
Similar to cookies
But not such a small limit
Not every browser supports it (may need polyfill)
Form/Post/Hidden/ViewState
You could just post the data and drag the information from response to response
But this gets really annoying with back buttons & timeouts
Lots of work, and again, the user can tamper with the information

Store large amounts of data per session ASP.NET MVC

My MVC based application, hooks some web services which send back lots of data!
Using the same, I render my views. The web services are slow and out of my control.
So I would like to store this info per session, but I am afraid that, this will bring down my web server to its knees. With few hundred users, the web server will run out of memory.
Is there a way that I can store this session data in a file per session? I am more looking at some out of the box open source solutions.
I welcome, new suggestion as well!

You can store pretty much any object in the Session storage, with a few exceptions which are generally related to running on a server farm. I'm going to ignore those cases here however.
If you're dealing with only a few MB of data, storing it in the Session object (or a Cache, as #Rick suggests) isn't necessarily a major problem. Once the data has been returned from the web service and parsed into your own internal data structures, simply place the data structure's root object into the Session. I use this method fairly often to store the results of database queries that take a long time to run, especially when the query criteria are unlikely to change frequently.
For larger data sets you should probably use a database to store the information. Create tables that match the structure of the data you're returning and tag the data in some way to indicate how old it is and what criteria were used when fetching it. Update as required, and query the database for records on each client request.
There are plenty of other options, including creating temporary files to store the data using the SessionID to identify them, but I recommend investigating the database option first.

Caching is your friend. And since you use MS technology you might want to take a look at the Cache Class

You could just serialize the result collection and save it on files as xml (even process it using linq/XPath directly from XML) , or use any .net native xml database to store and persist data on a file.

Data cache vs session object in ASP.Net

Should dynamic business objects for a site be stored in the users session or use ASP.Net caching (objects such as orders, profile information etc)?
I have worked with sites that used sessions to store business objects, but I was wondering...What are the advantages or disadvantages of caching?

If the objects are shareable between user sessions, then use the cache. If the objects are unique to each session -- perhaps because they are governed by permissions -- then store it in the session. The in-process session itself is stored in the cache so the deciding factor really should be the scope of the data.

Caching is just that -- caching. You can never rely on entries being there, so no assumptions must be made in that respect: be prepared to go straight to the DB (or wherever else) to refetch data.
Session, on the other hand, is more suited towards storing objects, though personally I try to avoid session store in favour of a DB. I usually do that by abstracting away the store behind an opaque ISessionStoreService interface:
interface ISessionStore
{
T GetEntry<T>(string key);
void SaveEntry<T>(string key, T entry);
}
and then "dependency-injecting" appropriate implementation, be it InmemorySessionStore, DbSessionStore or whatever.

The ASP.NET system cache is global to the application where as the session is unique to the current user. If you chose to use the global cache to store objects you would need to create an object identification strategy so you could get the correct objects for your per user basis.
If you are looking to enhance performance you would be better off replacing the ASP.NET session state with a distributed memory cache such as Microsoft's velocity. Microsoft has posted articles on how to replace session usage to target Velocity. You could also use Memcache or other similar products in a related fashion.

Session objects are suitable for user-only-data, on the other hand, Cache objects are more suitable for data shared for the application.
The key to save in one or the other is to determine if what are you trying to store will be user-only data or it needs to be shared in all the application.
Session => A webpage with a step by step interface (an online test for example).
Cache => The info displayed in some kind of weather widget (like the one that google has in its igoogle.com page).
Hope this helps.

Although you can store your business object in Cache, but Cache is designed for performance improvement not state management. Imagine you that you have a process of getting 1000 record from database (and it take about 3 seconds) and you will need it for a few minutes. You can store your objects in Cache and set expire date, priority and dependency to it (like SqlDependency or FileDependency), so for next requests you can use Cached data instead of retriving it from database. You can store your object in Session but you can not set dependency for Session by default. Also Cache has a unique behavior that when system needs memory it will release objects from cache depending on its priority. Cache objects are global to Application and shared between all users but Session is not shared and it's usable for each user (Session).