How to choose whether a web page should be a web user control?

Question

A few guys on our team are of the opinion that every web page in the application should be a web user control. So you'll have all of your html + event handling in the Customer.ascx, for example, and there will be a corresponding Customer.aspx page that contains Customer.ascx control.

These are their arguments:

1. This practice promotes versatility, portability, and re-usability.
2. Even if the page is not re-used right now, it might be in a future.
3. Customer page might need to move to a different location or renamed sometimes in a future and moving user controls is easier.
4. This is a recommendation by MS for new development.

Is this really a recommendation for new development? Are there any drawbacks to this strategy? I agree that it's nice to have a user control on hand if the need arises, but it seems to be an overkill to do this to the entire application "just in case we need it later".

Answer 1

1. Seriously complicates client-side script as the NamingContainer jiggery will prepend _ctl0 etc to everything sometimes.
2. I don't think MS ever recommended it. Request links to MSDN documentation.
3. Typically by the time your are done implementing something, and it is sufficiently complicated, you'll find a lot of "gotchas" when ever you try to "reuse" it. A good example is relative links in the user control that no longer work outside of their path.
4. Users don't need the ability to add/edit/delete Customers on every page. Indeed, you start to get into caching issues if you have these types of controls on every page. For example if on an Invoice page, you add a Customer, will the Invoice control be updated with the new Customer? All sorts of inter-control operability issues can manifest. These issues are hard to argue for, because of course, everyone's user control will be perfect, so this will never happen. ha ha right.
5. See if they can come up with an example where moving/renaming a user control actually saved time, instead of making it more complicated. Draw up an actual example and show the pros/cons of each.

Answer 2

Personally I'm not a fan, I think it adds a layer of complexity to the application that is not strictly necessary at the early stages. If you need to reuse a component that you had not previously thought would be reused, refactoring it into a user control at that point should not be very difficult.

Answer 3

1, 2 & 3: Doing anything because "you might need it later" is a horrible strategy.

http://c2.com/xp/YouArentGonnaNeedIt.html

4: I have never read this and seriously doubt MS has ever said anything like this. Maybe some random article by one single person who has an MS tag or was an MVP or something, and a gullible junior dev took it as Gospel Truth.

Answer 4

I came across an application in .NET 1.1 that was written like that once. Someone must have heard that same misguided "best practice" and taken it for the absolute truth.

I agree that it adds a level of complexity that's mostly not needed. I usually find usercontrols more useful for something like portions of a page that are repeated on several pages. If you think you'd reuse the entire page... why not just use the original page?

I also don't understand the moving/renaming argument. It's not that difficult to rename/move a page. If you do what your colleagues are suggesting, you'd end up with a customers.aspx page that contains nothing but an orders.ascx file? I see more potential confusion/errors with that approach than by just renaming/moving a file.