Windowstemplatestudio: Code Behind: Page vs View naming

Created on 28 Mar 2017  路  8Comments  路  Source: microsoft/WindowsTemplateStudio

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.

Can Close Out Soon Microsoft on point help wanted question

All 8 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.
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.

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.

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

Fixed in branch may

Merged to dev in PR #137

Was this page helpful?
0 / 5 - 0 ratings