A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Read somewhere that "Software as a Service (SaaS)" model is the future of application development. Even for a LAN, applications are using Application Servers like ASP.NET to facilitate deployment and maintenance.
When does the need for desktop applications arise? Can ASP.NET be used for a departmental level application consisting of 1 server and few nodes?
Let's not do this topic AGAIN please....
Don't believe everything you read. SaaS has been around for a long time in many forms and many of them have failed. That's not to say that SaaS can't work. But it's hardly the "future or software developement".
Thursday, August 09, 2007
I also think RK is mixing buzzwords in the wrong context. (Or I am confusing the term.)
"Software as a Service" refers to a subscription based payment scheme where you fork over the cash for the application as you use it. In theory, if you only use Micrsoft Word for a week as would be the case if you were a student or a temp employee, you pay a prorated week's worth of the Microsoft Office sticker price. If you wind up using it a full year, you pay that much more.
ASP.NET and other web based paradigms are ideal for "Software as a Service" because you'd control the server itself and can deny the application to users who won't pay. It's much harder, in fact almost impossible to enforce SaaS using a traditional desktop application because the user may not be connected to the Net, and the user usually has tools and techniques available to circumvent your protection schemes.
Keep in mind that the whole concept is centered around making you pay for the software you use, based on how much you use it.
There are many situations where SaaS is not practical or ideal, such as when you've written your own software for use on your own internal, corporate intranet. Why would you charge your own employees?
That said, if you're creating a program for use within a LAN, choosing ASP.NET in web applications or VB.NET/C#.NET in desktop applications is largely deciding between a rich user interface/local processing (fat client) verses centralized management/server processing (thin client). There are pros and cons for each approach.
Deciding between charging a flat fee, verses charging a subscription, is a completely separate and often unnecessary decision.
Thursday, August 09, 2007
Note that it is perfectly possible to offer SaaS using software that is a thick client through something like Citrix.
In fact, this is a very common internal deployment strategy for large enterprises. Some specialised ASP vendors also use this to support a SaaS business model.
So the architecture of the software doesn't necessarily limit your options for deployment - some exceptions being video editing or CAD etc.
I currently developing a WinForms smart client to be deployed on a large scale over Citrix using a SaaS-like business model.
It's not "Desktop App. vs. SaaS", neither is it "Desktop App vs. Web app". You can have your cake and eat it.
Friday, August 10, 2007
"Leaving it behind, what you all think is the future, Fat Client or Thin Client. For a department level application, what should I prefer. "
You should 'prefer' what ever is the best tool for each situation. There are pos and cons to every technology, so you need to take a careful look at the requirements for each project and determine what technology is the best to use.
"You should 'prefer' what ever is the best tool for each situation."
There isn't always (and indeed, there is rarely) a hard and fast "this tech is better for this scenario" answer. When it comes to web-based vs. thick client vs. thin client -- all could work very well for most types of B2B and B2C applications.
Also, as much as we might hate it, coping with the marketing aspect of the technology we select is a big part of it. Building a better mousetrap isn't good enough, you need to market the hell out of it. Being able to convince someone who really isn't qualified to make a decision about the software to choose is part of the reality of software sales.
There is no doubt that an n-tier design is going to be the most flexible in terms of distribution of work and scalability, and if it's done well you can provide both a web client and a more rich native-Windows/OSX/Linux/DOS/Whatever client, thus getting the best of all worlds. This is, however, significantly more difficult than, say, writing it with an MS Access back end using Visual Basic 6.0, both in terms of design effort and implementation effort.
If, by "department level" application, you mean that you're whipping it up for use internally within your own department, and you're not selling it to anyone and the needs are pretty well defined, a thick client is going to be the fastest way to do it.
At the moment, I personally develop using an n-tier architecture, for the most part.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz