Comments on: Software Architecture Cheatsheet (Part 2/3)

By: Software Architecture Cheatsheet (Part 3/3) | Software Artist

Software Architecture Cheatsheet (Part 3/3) | Software Artist — Thu, 07 May 2009 14:14:09 +0000

[...] the previous post, I tried to think of the business constraints that intervene in the choices of a software [...]

By: Sébastien

Sébastien — Thu, 07 May 2009 09:19:48 +0000

Hmmm… let’s see… Cross-site scripting, SQL injection, brute force password cracking, denial of service, all things that simply don’t exist when your application is only accesible through a desktop app.

Now what you say about a desktop app is another problem. It’s a matter of design: IMHO, you should NEVER EVER transfer pure SQL over the wire or know the address of the DB on the client side. But this could be the topic of a next post.

Finally, believe it or not, there are still applications that simply don’t require any distributivity, no DB, no server-side. In those cases, proposing a web-app architecture is a little like commuting with a tank, don’t you think?

By: Catering to those with disabilities - Web Design - An Insight

Catering to those with disabilities - Web Design - An Insight — Thu, 07 May 2009 09:05:08 +0000

[...] Software Architecture Cheatsheet (Part 2/3) | Software Artist [...]

By: raveman

raveman — Thu, 07 May 2009 08:40:26 +0000

I dont understand why you think that web-apps are less secure. i think they are more secure, because nobody has access to the source code and you can crack it.

in desktop app i can interupt what is send to server(its pure sql being send to db) and with web-app i dont even know the address of db server.

Most of the security problems in web-app are also in desktop app(except XSS)

By: Mr. Hericus

Mr. Hericus — Wed, 06 May 2009 16:59:27 +0000

Under the subjects of Maintenance and Continuity, you also have to consider more than just the application that you are building. You have to consider the supporting structure that surrounds your application, e.g. the tools that are used to actually create and build your application.

Longevity means more than just being able to bring new people on and get them to understand the code. Your code, your tools, and your process have to survive people leaving the team, and people being added to the team. If your code is well documented, but your surrounding infrastructure is only in one persons head, you’ll still have longevity, maintenance, and continuity problems.