Should I use ASP.NET Profiles here?

I'm working on a rewrite of a website that has to pull its user data data from a third-party system accessed via remote objects. In the interest of standardization, I've implemented a custom MembershipProvider for authentication and a custom RoleProvider for authorization, but I'm now pondering the best way to deal with profile data. Most of the advice I've seen says to use the ProfileProvider model to deal with profile data if at all possible, but its design really seems not to mesh well with the system I have to interface with.

The biggest sticking point is the ProfileProvider's insistence that a Profile is a bag of objects that is operated on as a single entity. That may fine for a SQL-based provider, but calling the remote objects is a very expensive operation. If I make a call to Profile.FirstName, GetPropertyValues looks like it's sent a SettingsPropertyCollection containing every object defined in the profile. For this website, that will include multiple sets of address information, order information, attendance information, and other things besides. Pulling all of that information at once is murderous on performance. It does look like targeted saves can be done through use of the IsDirty flag on each SettingsPropertyValue object, but only if it's a primitive type... which most of the properties aren't.

Am I understanding this correctly? If all the P开发者_如何学GorofileProvider provides is "Return this profile" or "Save this profile" then lazy loading seems impossible, and the performance hit is too great. If I ditch the profile model, what's a good alternative method for dealing with all the profile data? Should I just roll my own session-backed mechanism?