There are fundamentally two architectures.
Standalone and online. Any discussion we can have about the merits and
demerits of both have been repeated ad-nausea for every application
since the birth of the Internet.
If we try to boil the ocean on the first pass, the project is doomed
from the beginning. Can you image what would have happened if Linus
Torvalds had tried to release Red Hat as a replacement to Minux?
Get something that works well and that installs well on a local machine.
Refactor it so that the business tier, the presentation tier and the
model tier are distinct.
Drop it on a disconnected appserver and add an additional presentation
tier to prove that the refactoring is sufficient. It won't be, so count
on additional refactoring.
Now you have a functional solution that is worth debating
security/privacy/convience issues about taking online.
The worst case scenario is, you have a solution that works for you, and
that others can install and that will work for them.
Pushing security concerns into the application logic itself, is IMHO,
absolutely poor design!!! Security and security policies are
cross-cutting concerns that should be done declaratively in a security
policy manager, or at worst, in the appserver.
As a ward member, do you really want to have to log in and validate
against every piece of functionality restricted to members on the church
website. Ex: Once I log in once, switching to the ward webmaster mode
doesn't require a new authentication. Why? Because the authentication
is done at the middleware layer, not the individual application layer.
--
A. Rick Anderson
_______________________________________________
Ldsoss mailing list
[email protected]
http://lists.ldsoss.org/mailman/listinfo/ldsoss
