In truth, for a church site, I’d tell the client to give me some $ to research and manage an offshore Joomla developer. With all the Joomla plugins it’s *really* easy and cheap to get something with a tons of generic functionality up.

If its likely to be you and you do see future complexity coming along then I’d go for a layered domain model based approach, but with something like a church website I might even be thinking active record (as Joe suggests). I say this because I’d imagine CRUD and a little bit of validation is as complex as it will ever get to be so active record might be a good choice.

However, if you must stay with .NET, I’d absolutely agree that a Castle MR/AR combo is a great way to get something up and running fast without sacrificing too much of the architecture.

@Gabe,
Indeed, I struggled with this myself, on purpose mostly by setting up my Ubuntu box at home. I like to “feel the pain” of something before looking to make it easier or have someone else do it for me. I ended up just getting a RailsPlayground account ($5/mo) and set up Capistrano accordingly. Now it’s drop dead simple “cap deploy” and it’s all good.

> When do you decide if a solution is complex? It seems
> that the supposedly short-term apps tend to hang around
> the longest.

No idea

But I’m reading through _Design Patterns_ again, and the whole book in one sentence is “encapsulate the concept that varies”. I think the best you can do is choose a few of the axes along which you thing future variation is most likely, and make sure your architecture encapsulates those.

About Rails, incidentally: I’m also building a web app for my church, and decided to use the experience to teach myself Rails. The actual development has been a joy, but I’ve spent almost as much time deploying it as I have developing it . If you don’t have prior knowledge of linux/apache, it can be a pain.

How likely is it that I’m going to be introducing significant architectural changes? If I think it’s likely that the scope of a project is going to grow over time and I’m going to have to have a flexible design… invest the time to do it ‘right’.

I think the real trick is being faced with new feature requests and knowing when it’s time to refactor things to a more flexible design (before it’s too late).

Sounds like we need a RoR install-fest in Austin.

@Chris

I keep hearing that. Sounds like I need to bite the bullet.

@Peter

I understand that familiar approaches are faster, and picking a good architecture helps you scale. I’m trying to figure out if there’s a threshold where less flexible technologies are appropriate. Not sure if there is one.

@Gabe, @Nick

When do you decide if a solution is complex? It seems that the supposedly short-term apps tend to hang around the longest.