On 10/7/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > I don't know about you, but I see *WAY TOO MUCH* overengineering in many > projects. People are so anal about coming up with the absolute perfect > architectural solution. I'm not saying we shouldn't strive for > perfection, of course we should, but it's no wonder so many projects run > over deadline and/or over budget... sometimes bending a rule here or there > isn't the worst thing. The trick is knowing when bending becomes breaking > to the detriment of the future, as you alluded to earlier :)
My leitmotif is always: keep it simple. No ibatis, no hibernate, no ejb, no nothing unless you explicitely can prove that you need it. Build a vertical prototype, build it fast, test it, give it muscles. Very XP-like, or maybe beyond XP. If something is not sufficent anymore, replace it. I think the perfect architecture contains everything you need, but also ONLY things you need. Therefore it can't be overengineered :-) But this approach requires clear separation of (vertical) layers and (horizontal) modules, so you really can exchange them. I often hear, exchangeability of the database is not needed, noone ever exchanges the db in the real world, and if they do, the have to change everything either way. We actually really do exchange the db daily. Our complete application runs in production on about 25 servers. I can reconfigure it to use filesystem based persistences and run it on my notebook if I want to work on the road. It runs with corba in production but I can reconfigure it to use direct java calls (with local instantiation) or RMI, or whatever SOAP, or whatever we will decide (and implement) tomorrow. (Sofar for self-advertising :-)) > > The app I was describing has been in production under heavy usage for > almost 3 years now, was originally not even Struts-based (it is now), has > given us very little trouble along the way and has been very extensible to > boot in terms of new client usage and new feature implementation. It is a > big success story by any measure that matters in my mind. I don't feel > bad about the decisions we made, even if they aren't 100% "best practices" > :) If it works its perfect --> XP. Why should you change anything in an existing application if you don't have a requirement to do so :-) > You are right though if I extend this further... the BUSINESS DELEGATES > know too much about persistence. That *is* a flaw in the design that I > didn't recognize when they were written. Hey, live and learn :) It's not > as big a problem as the Actions knowing too much, but it's still a > problem. Hasn't burnt us in 3 years, but it's a mistake I haven't made in > subsequent projects. I think by time it would become a problem, you would know how to change it, so its not a REAL problem. The REAL problem I often see, is that developers don't have the guts to say to the manager: "Ok, this is a complete new requirement, so I have to change alot, even it looks like an hour of work to you, it's a week for me". Instead they start to hack. Half year later the application dies because of major architectural flaws... (Surely would the developer have the guts and tell this to the manager, noone can assure that the manager has the appropriate answer, but most managers I know act quite rational, if you can explain the problem to them in their language (like we save one week of my worktime now, but loose 3 days of sales in two month...)) > > That's all good, but doesn't conflict with what I've done. The only > difference is that I've chosen to not transform from one exception type to > another anywhere along the way, and I don't log at the "lower" levels. > But, you could do what I do and still do everything you outline here. > That's the nice thing about the global exception handling mechanism. Then it's perfect. The only problem I have with transporting exception through layers, is if you change your persistence layer (for example) you have to touch your presentation layer, and this makes changing layers harder. Therefore I prefer that each layer hides the underlying layer from the upper layer. > > > Everything in this mail is just a private opinion :-) > > Same here of course :) The thing I always point out is that Best > Practices are so named for good reason, but they are not called "Only > Practices". We can recognize the "best" way to do something, but still > recognize that there are other ways that are valid as well. Sometimes > people get very closed-minded and only want to talk about best practices > like there is no other way to do things (not implying you fall in that > category by the way Leon, just saying some people do). I personally hate > that. Best practices should be guidelines, a plan that should be the > starting point and the preferred solution from the start, but not to the > exclusion of other ideas. :) +1 :-) > Frank Leon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
