JC,
I'm a SF user (so this isn't an official SF response) who is in the process of doing exactly what you have described: taking an Access app, connected to a SQL Server 2000 database and converting it to SF/.NET. Down the road, I'll be turning it into SAAS (once I get the actual app running) and I see limited web front ends in its future as well. I've been using SF for about a year now (11 months, if you include my trial time). When I started I was new to .NET as well. First I'll give you my answers to your questions:
1.Is SF a good choice for this type of project?
Very good choice, for a lot of reasons.
First, .net is just a whole lot more powerful than Access was. You have a zillion controls, including the extended ones from SF; you have real OOP so you can subclass; you have constructors...the list goes on. That power comes at a price though. Access did a lot out of the box, especially related to data access. This was daunting when I was considering .net (or anything else for that matter). If you just use to build your app .net, you have
a lot of coding to do to get the same functionality that Access provides for you with no work (data binding, concurrency, data retrieval, loading combo boxes/list boxes, etc.). This is were SF comes in. If provides many of those functions. Using business objects (BOs), binding is easy, data retrieval is easy, business rules are easy, filling list/combo boxes is easy. Nice
Second, as you mentioned, there is the other stuff in SF: role based security, the DDT, lots of UI controls (PanelManager, themed controls, link menu, gradient header, etc.), plus a ton of other tools (thread manager, registry support, error handling tools, xml and compression classes...the list goes on).
Third, you aren't boxed into a corner with them. You can extend your own controls or third party control to support data binding using SF BOs, and this is pretty easy to do. You can use the BusinessBindingSource to use ADO.NET binding with a control (like with grids). You can add custom properties to BOs, directly manipulate the data in a BO (if the standard methods don't work), extend how a BO works...
Fourth, there are a bunch of samples (with source) and when you purchase SF, you get the source code. This, it turns out, is amazing helpful. I use it all the time to figure out how to do things in .NET/SF. The samples are very helpful to figure out how to actually do something using SF. Need to provide binding to a non-SF control, there is a sample that shows just that. Need to figure out how to fill a listview, just check out the samples. The source code for SF is very helpful too. I've used it a bunch to figure out how things are done in .NET. Of course, having the source means that you can also change SF if you need to (not recommended, cause then you have to deal with reconciling your changes with updates from SF). I've seen this done when a bug is found that is complicated to fix for the SF team (because they have to think about all the possible uses of any given feature), but the fix for the specific developer was easy (they don't care how anyone else is using it).
Fifth, the support for the product is excellent. Let me amend that, it is amazing. Not only have I been able to get many SF related problems fixed, whether it is something I'm not understanding (very common
) or there is a bug in SF code, they are very responsive. They often release fixes related to specific problems immediately when the developer needs that fix. Even more amazing, they also help with general .net problems. I've learned a ton about .net development here in the forums.
2.How robust would SF and its ES in a Smart-Client SAAS scenario be?
Based on what I've learned it is robust. ES is very nice. I'm about to deploy it and all testing indicates very nice performance.
3.How effective is the ES and SF BO on a website?
I have very limited experience with this, but BOs allow you to reuse your business logic with multiple font-ends. Not sure how effective using ES with a website is.
4.When will SF integrate with VS 2008 .NET 3.5 and how will LINQ and its OR/M affect SF future?
What I've read on the forum indicates that SF will currently work with VS 2008. They have worked on LINQ, but aren't going to release anything until
after VS 2008 is officially released, at which point LINQ will be available (in what form I don't know).
I'm sure one (or both) of the SF developers (Ben or Trent) will chime in with more info/better info
I just wanted to let you know that you aren't the first in this situation and that, so far, I'm really, really happy with SF, both the product and the team building it and provide some of the reasons I'm digging it.
Finally, if you do decide to go with SF, I'd highly recommend the training class. There is one scheduled for early December. The secret about SF is that these guys aren't really framework developers, but application developers who needed a framework
They have the same problems
we have and build the framework to fix those problems. I really think they need to start offering a class that is about application development strategies/techniques. They do a lot of that in the class as it is and those are the gems....oh and Trent buys the beer for everyone
Good luck with your conversion!