I really don't buy the "code lives with data" thing. With this approach, after a while you get the octopus of a User class, aware of everything going on in your application -- authentication, the fact it's a web app, transaction management, parsing of itself from xml, marshalling itself into xml... where do you stop applying this "code lives with data" principle? And, actually, the classic separation of concerns, together with testability-oriented thinking, produce a lot of nice small classes, logically self-contained, easy to understand, use, and, yes, reuse. But reusability is not the only reason why you don't clump together concerns -- it's just one such reason.
Sure, if this is a tiny singular occurrence in your app (say, the only place in a tiny app authentication is ever dealt with), go ahead and put this method as a convenience. But surely we're not talking about such cases? Small unimportant apps can take a certain amount of clumping together of code dealing with different concerns before they become a complete nightmare to work with -- but who cares about those apps?
No comments:
Post a Comment