OK - this is about as far away from CSLA as you can get. But I've seen some pretty smart folks here...
I'm beginning to do some work on a project for my wife to help her manage a business she runs out of the house. I will be using CSLA for the project, but this will be a single-user desktop app. I suppose it's possible that it could expand to multiple users, but that's not something either of us see in the foreseeable future.
Anyway, this will be on her laptop, and she will have some percentage of work done out of the house - and off our internal network. She may go to places where she has internet access, and she may go to places where she's got nothing but her laptop.
We have a web server that hosts a site for her, and it's also hosting SQL Server 2005 for my development work. Since she's already talking about incorporating some functionality into her website at a later date, I decided to forego using SQL Server Express and just go directly to "the big box".
Classic "smart client" scenario, right? Well... here's where I'm probably overthinking it.
The plan is to support three modes of data - direct SQL Server connection (for when she's at home), a web service (for when she out, but has internet access), and disconnected local (for when it's her and the laptop). My question relates to how to manage that data synchronization. I'm going to be building a facade in front of all this that my CSLA objects will interface with, so that they never have to know which data-access methods are available.
The longer I look at the problem, the more I'm leaning towards just having everything run off the local data, and have the SQL Server/web-service update as an "extension" after the local-data update. The reason for that is that I don't want her to have to remember to sync the data to her laptop before she leaves the house. Plus, it makes the facade a little easier, since the facade essentially becomes the local-data update.
The issues are obvious - do I really want the entire database stored locally in persistent files? That's a big download hit - but it only happens once. After that, it's all incremental updates. There's no concurrency issues - she's the only user. The functionality of DataSets in .NET provide me with just about everything I need from a referential-integrity standpoint, but I have to be careful about it or else I'm potentially using a huge memory footprint. Obviously this also adds another layer to the update process, which adds more time. And it's not the most efficient from a database perspective either - my options for grouping operations in stored procedures is pretty limited under this scenario unless the local schema deviates quite a bit from the database. But the number of record updates for any operation is pretty minimal, and if I take a little time to build a localized transaction logger, I can isolate the records to update pretty quickly.
Storing the entire database locally also allows me to give her full functionality wherever she is, which is not as important as it sounds, but would be a "nice to have". However, she will need enough functionality offline that the amount of data I'd have to synchronize is not much less than the entire schema anyway.
None of this fits very well within a web scenario, but the kind of functionality she's wanting from the web page is largely report-based, so the facade wouldn't be much use there - and neither would my CSLA objects.
I considered using SQL Server Express locally and setting up some merge replication, but that seems like using a sledgehammer to kill a fly. Of course, storing the entire database in persistent DataSet-based cache files is not exactly a lightweight solution either... but I see it as easier to manage for schema changes than an actual DB.
So what am I missing? Why is this an idea I should run away from? Should I just use SQL Server Express?
- Scott
tmg4340:
The longer I look at the problem, the more I'm leaning towards just having everything run off the local data, and have the SQL Server/web-service update as an "extension" after the local-data update. The reason for that is that I don't want her to have to remember to sync the data to her laptop before she leaves the house. Plus, it makes the facade a little easier, since the facade essentially becomes the local-data update.
In general I think this is the right answer and is what I recommend for most apps like this. Think about Outlook in cached mode, it always works against its local data store, and then does background sync to receive/send data.
Microsoft is investing pretty heavily in making this model easier/better. Look at SQLce and SQL Sync Services. They are building the infrastructure so you can use SQLce on the client, and use sync services to do most of the hard work of getting the data to/from the central database.
The problem we ran into with always using a local store with background sync is that if the db your working with is a large multiuser backend keeping the whole thing in sync is not feasible. Yet if the user does have a connection to the core system they should have the benifits of searching the whole thing (at least in our situation). Outlook doesn't really have this issue since it's just replicating your inbox not everyones mailbox.
This may not be an issue with your app though.
The way we did it was have used a web service for all network connectivity, and the XML used for the web service was cached locally if offline. So if you had connectivity you had the benefits of the large db, while offline it just returned results from the local XML cache but CSLA always saw the web service as active.
Justin
Microsoft is investing pretty heavily in making this model easier/better. Look at SQLce and SQL Sync Services. They are building the infrastructure so you can use SQLce on the client, and use sync services to do most of the hard work of getting the data to/from the central database.
Thanks for the info. I didn't know SQL CE had "graduated" to the desktop. SQL SS is still in beta, and I don't think I can wait for the Orcas release, but I'll take a look at it. Hopefully it's far enough along that I can use it. From my initial look, it sounds pretty much like what I would have written anyway.
The problem we ran into with always using a local store with background sync is that if the db your working with is a large multiuser backend keeping the whole thing in sync is not feasible. Yet if the user does have a connection to the core system they should have the benifits of searching the whole thing (at least in our situation). Outlook doesn't really have this issue since it's just replicating your inbox not everyones mailbox.
This isn't a multiuser backend - my wife will be the only user for the foreseeable future. In fact, if my wife wasn't thinking about adding some functionality to her website in the future, I wouldn't even be thinking about this - I'd just keep the data local to the app. So all data in the "big backend" is hers anyway. I'm just trying to save myself headaches for the web parts later.
- Scott
If this is how "Big Brother" is doing it...
http://blogs.msdn.com/dieterz/archive/2005/11/07/489893.aspx
...then it's good enough for me.
If this is how "Big Brother" is doing it...
http://blogs.msdn.com/dieterz/archive/2005/11/07/489893.aspx
...then it's good enough for me.
I thought about doing it this way - just dumping the direct SQL connection and doing everything through a web service. I may still do it. But she will be working from the house at least half the time, and I didn't want the app to incur the web-service overhead unless it was necessary.
It's interesting to see how MS is moving more of their apps to the "Outlook style"...
- Scott
Copyright (c) Marimer LLC