-
Notifications
You must be signed in to change notification settings - Fork 458
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Code Behind: Page vs View naming #80
Comments
I'm all for view as it's what I use in my day to day work as it makes sense with the MVVM pattern. As you've mentioned, doing this will keep it simple for anyone working with an MVVM framework. |
I use *Page for the things you can navigate to, and *View for the rest of the content displayers (user controls). But that's just a habit, I wouldn't mind switching to a *View suffix for all of these. After all, it looks silly to have a folder called "Views" with all its classes ending on "Page". |
I set out to say that I don't think it matters either way as long as it's consistent but my arguments have actually led me in a different way. If an item needs a suffix to make its function, use, and intended purpose clearer then it should be as specific as possible. Adding a 'View' suffix says what it is used for. Adding a 'Page' suffix says what it is and what it is used for as within a UWP app pages are used only as views. That they're in a folder and namespace called views already states that it is a view. The From an architectural pattern perspective, Views aren't just limited to pages or even controls. There's an argument that LiveTiles and ToatNotifications are also part of the view layer, but I wouldn't expect anyone to give them the 'View' suffix. The folder (or ns) something is in shouldn't automatically define a suffix that is applied to an item. Would you also propose appending 'Model' to everything in the "Models" folder? I hope not. The reuse of views isn't a goal of MVVM so I don't see this ("naming pages Views is much easier from a reuse perspective due to MVVM") making sense. The only way the naming of something could aid reuse would be if you potentially had different things with the same name and I'd recommend against such a proposal. Thinking more widely, the "Views" folder could end up also containing things way beyond In conclusion, if adding a suffix is necessary to add clarity then adding something specific that adds extra information, rather than a generic term which also matches the folder/namespace it is in is a bad idea. I vote for the 'Page' suffix to be applied to the name of Pages in the "Views" folder. p.s. I'm NOT also going to use the above arguments to debate against having a "ViewModels" folder which contains classes with the suffix 'ViewModel'. That's a common and useful approach based on how ViewModel classes are used within code. |
Just also found #41 - Are these issues the same question? |
Putting my Mort hat on: if people are used to seeing MainPage, then it should still be Page. Databound templates in the past used Page. |
Fixed in branch may |
Merged to dev in PR #137 |
Community, from a pure template perspective, naming pages Views is much easier from a reuse perspective due to MVVM.
Do you feel this is OK? So rather than MainPage, we'll have MainView but treat it just like we would a page. These would live in the View folder as well.
The text was updated successfully, but these errors were encountered: