I am designing a .NET web community app (ala MSN, Yahoo) in C#. I want it to be as OO as possible, but maintain scalability and performance. Here's what I have so far...
Create a Member object when a user signs in. Run a single sproc that returns multiple result sets to populate various strings, ints, and DataTable properties of the Member object. Store the Member object in Session. DataTables represent 1-to-many relationships, like a member's buddy list. SELECT/UPDATE/INSERT/DELETE methods for each table are methods of the Member class. When a data-modifying method is called (UPDATE/INSERT/DELETE), the sproc returns a fresh copy of the data to repopulate the DataTable being changed. Outside of the initial bulk load, the DB is hit ONLY when a data-modifying method is called, since the user-specific data is pre-cached. This heavily minimizes DB hits, keeps small chunks of user data close at hand, and maintains an OO design. What I am concerned with is how well it will scale, perform with lots of concurrent users, and work in a web farm scenario (assuming use of a dedicated state server)? Also, would saving these DataSets for Members in Cache be better than stuffing them into Session? Thanks in advance... Francesco Sanfilippo ASP, .NET, SQL, C# San Diego, CA. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
