Skip to content
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

Closed
crutkas opened this issue Mar 28, 2017 · 8 comments
Closed

Code Behind: Page vs View naming #80

crutkas opened this issue Mar 28, 2017 · 8 comments
Assignees
Labels
Can Close Out Soon Work relating to this issue has been completed. help wanted Issues where external contributors are wanted to help address the issue. Microsoft on point Indicates that community contribution for this issue is not being sort. Typically because it relates question Indicates that the issue is an open question on how future functionality should work.
Milestone

Comments

@crutkas
Copy link
Member

crutkas commented Mar 28, 2017

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.

@crutkas crutkas added help wanted Issues where external contributors are wanted to help address the issue. question Indicates that the issue is an open question on how future functionality should work. labels Mar 28, 2017
@crutkas crutkas added this to the 0.5 milestone Mar 28, 2017
@jamesmcroft
Copy link
Contributor

jamesmcroft commented Mar 28, 2017

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.

@XamlBrewer
Copy link

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".

@mrlacey
Copy link
Collaborator

mrlacey commented Mar 28, 2017

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.
MyApp.Views.MainView has unnecessary redundancy in the name by saying "View" twice.
MyApp.Views.MainPage avoids the redundancy and provides extra information about the class.

The Views folder is intended to contain items that fulfill the role of a "view" in the MVVM pattern. The item acting as a view doesn't have to be a Page, commonly they're also represented with UserControls but could be anything that can be displayed in a Frame. Would you use the '*View' suffix for everything in that folder? Pages, UserControls alike? I wouldn't expect so as doing this could cause confusion.

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 Pages. Imagine an app where on desktop, mobile, xbox, & team displays the visual representation of the view is a Page but on a VR/AR device the representation could be something very different. For example. While You may have a SettingsPage for traditional displays, and a very different SettingsObject for holographic output. I wouldn't want them both called SettingsView.

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.
Ideally, we wouldn't need any suffix for views but in reality, there are very few cases where this is appropriate and having a convention is good.

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.
p.p.s. If you think I'm arguing for a Hungarian Notation perspective then it's very much apps Hungarian rather than system Hungarian.

@mrlacey
Copy link
Collaborator

mrlacey commented Mar 28, 2017

Just also found #41 - Are these issues the same question?

@gcaughey
Copy link

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.

@crutkas
Copy link
Member Author

crutkas commented Mar 28, 2017

@mrlacey looks like you are correct, lets merge #41 to this

@ralarcon ralarcon added the Microsoft on point Indicates that community contribution for this issue is not being sort. Typically because it relates label Apr 3, 2017
@mvegaca
Copy link
Collaborator

mvegaca commented Apr 4, 2017

Fixed in branch may

@crutkas crutkas added the Can Close Out Soon Work relating to this issue has been completed. label Apr 5, 2017
@ralarcon
Copy link
Contributor

ralarcon commented Apr 6, 2017

Merged to dev in PR #137

@ralarcon ralarcon closed this as completed Apr 6, 2017
@ghost ghost locked as resolved and limited conversation to collaborators Jun 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Can Close Out Soon Work relating to this issue has been completed. help wanted Issues where external contributors are wanted to help address the issue. Microsoft on point Indicates that community contribution for this issue is not being sort. Typically because it relates question Indicates that the issue is an open question on how future functionality should work.
Projects
None yet
Development

No branches or pull requests

7 participants