Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.
"ASP.Net life cycle....I just find it counter-intuitive" I guess I'm saying the exact same thing about MVVM - dozens of lines of plumbing to replace Window.Show. However, I'm conceeding that the battle is pretty much already over and that many more people would agree with you than with me. I guess I'm trying to find justification - what problem are we solving - that would allow me to more easily accept this direction. Let me ask this - do those that enjoy MVVM work in an environment of separate backend/front end developers (maybe that's another question).
YAGNI - I'm not talking about writting a generalized library, but talking about using a pattern for a project that's likely to never grow large enough to realize the gains from such a pattern. Doing so may provide benefits of training, but also might be a nightmere to the inheriting developer. I do disagree that YAGNI is about writting code yourself and applies to all projects. We just did a project where archiving was a mandated feature prior to launch. A change control came thru shortly after that completely negated the need for that archiving system.
"patterns like MVVM were created to help developers build big systems" - I do get this and have considered sucking it up for the sake of more easily implementing it when it really matters. However "YAGNI" says not to do this - there's a real cost to the "guinea pig" both in terms of time and the caliber of developer required to maintain what should have been a simple project.
"When I worked in ASP.NET, I always struggled to bend it to my will" - can't say I ever had that problem - the asp.net page life cycle was always easy for me to manage. Client side development on the other had I avoided like the plague - the constant css workarounds, javascript inconsistencies, hell I can still argue the merits of a table over a div. The more stuff that happend on the server side to me was the more things that could be caught by the compiler and debugged in a fluid experience. The alternative felt clunky and that's how I feel about some of these patterns.
Thank you for the truely thoughtful response big ball of mud - I definately felt that way in the days of classic asp and spaghetti code. 3 tiered design with vb6/mts fixed a great deal of that, and then .net's release brought it all together. But now if feel the returns on additional patterns are rapidly deminishing - like spending $1M to take .1 sec off your quarter mile time. "I did aggressively push every bit of code I could out to a separate assembly" - don't you find that this gives an incredibly fractured development experience - constantly jumping from file to file to read two lines?
