The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Would appreciate some starting points.

Hello,

I have a small team of engineers that have been doing Client App development for a while now... we developed apps in .Net and QT so we are pretty experienced with 'Client Side' development. However, it is time to start moving the team to learn Web app development and I am looking for some starting pointers...

I would love to see if we can implement one of our apps (An interactive simpler version of Power Point) as a training case for a couple of folks in my team but I am not sure where to point them to.

We need something that could provide a very cool presentation layer, a simple, and flexible development environment and a solid DB.

How would you go about this?

Thanks!

-gb
G. Beard Send private email
Thursday, May 10, 2007
 
 
Don't start with an app suited to the desktop platform ("An interactive simpler version of Power Point") - this will be the most difficult to write as a web app. Start with a simple groupware-type app (bug tracking?!!) Since you have experience in .NET, I'd suggest looking at ASP.NET.
Mike Stockdale Send private email
Friday, May 11, 2007
 
 
Ruby on Rails, its what all the cool kids are using 9^)
Honu Send private email
Friday, May 11, 2007
 
 
It's possible to make the move to an n-tier internet app while staying with desktop clients.  Basically you just need to modify your clients to work with a middleware server on same machine or at same location as the db.  If that sounds like a possibility you may want to check out RemObjects and DataAbstract:

http://www.remobjects.com
Herbert Sitz Send private email
Friday, May 11, 2007
 
 
+1  Mike Stockdale

Your team will need to make a *significant* change in the way they think about application architecture. You're moving from an event-driven model where you control the entire process to a request/response model where a large portion of the application is outside your control. Desktop developers who don't break out of the desktop mindset routinely develop web applications which:

* Are insecure
* Are tied to one browser
* Require Javascript
* Break the back button
* Break bookmarkability
* Break if the user tries to look at multiple pages in multiple browser windows at once.

Your developers need to internalize the idea that they are dealing with a different environment which requires them to use different techniques and keep track of different concerns. That's much more likely to happen if they start with an application that fits the web well. Using as your first effort an application which is more ideally suited to desktop development than web development virtually guarantees the above problems.
clcr
Friday, May 11, 2007
 
 
"Your team will need to make a *significant* change in the way they think about application architecture."

It is true that you do need to make a big change in the way you're thinking if you move from building c/s desktop apps to web apps.  But if we're talking about your average garden variety custom c/s db-backed business app then there is far less of a change in moving to an n-tier architecture with "smart clients" accessing a middleware server.  Basically you design your clients mostly as you have been, but instead of having them directly access the db you change them to use disconnected recordsets that they get from a middleware server.  You would also probably move much of the business logic code from the clients (and possibly the db) into the middleware server.

Ease of distribution is just about the only disadvantage these n-tier apps have compared to web apps, and in many cases that's not a big deal.  You should easily be able to design a very rich client app that's 10MB or less, and these are generally "zero configuration" clients since the client machines don't need to work with any db library.  You just need internet access same as for a browser app.  Clients can just download and run.

Although ease of distribution is arguably a disadvantage with these thick clients, there are big advantages in (1) keeping same programming paradigm for clients, (2) flexibility in having centralized data processing in rich programming environment of the middleware server before sending recordsets or rpc results back to clients, (3) richness of client ui compared to browser-based apps, (4) power in being able to easily write complicated code to run on the clients, etc.

I realize browser-based apps are great.  But they aren't the ideal solution for every problem.  Rich clients and middleware servers provide an alternative that is better in some circumstances.
Herbert Sitz Send private email
Friday, May 11, 2007
 
 
Thanks for the input folks... I apreciate the effor and the insights.

Looks like taking an n-tier approach might be a good way to start for an interactive app. OR start with a more data centric app that could live totally in the server.

Regards,

G. Beard
G. Beard Send private email
Monday, May 14, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz