Logic in the Partial View vs Logic in the View vs Logic in a Controller
Hello people,
This is more of a question about the way you like doing things. I've been talking to other developers and there's a lot of way to do things.
Some people (like me) like throwing
@inherits UmbracoViewPage
in a partial view and then using the logic/variables in there (or some of it in a model, but not unless it's needed). Then rendering the actual view without any logic in it.
My boss for example, prefers:
@inherits UmbracoViewPage<CustomMVCModel>
and then just writing his data in his model and then doing something like @Model.text
In the view. That, creates more work but gets you strongly typed models, but my actual question is:
Which one do you think is best, do you have any other ways and which one do you use?
Like Alex, I too prefer the second option, for pretty much all of the same reasons.
As a brief note, if you're concerned about giving yourself additional work by creating strongly typed models for every document type in Umbraco (who really wants to do that eh?), then you should have a look at the ModelsBuilder package.
In a nutshell, this generates all of your models for you, saving you the hassle!
Models Builder is now built into the Umbraco core, so there's no need to install a package if you're on a recent version, it should be running already.
I'm also curious how other people do this as well. Putting logic in the controller is clearly the most 'MVC' way to do things, but it also means doing a lot of route hijacking. I'm leaning towards this approach anyway, because it's supposed to make unit testing easier, but unfortunately unit testing in Umbraco is difficult either way.
Putting logic in the model doesn't seem like a good idea, it goes against the purpose of the model.
I guess a lot of it starts with depending on your skill level and experience.
However, I generally also look to use typed models in most situations. There are a few exceptions, such as conditional logic that is needed in layout files etc but with Models builder being part of Umbraco there is little reasons for most of your views not being type safe.
You don't need to route hijack for partial views you can just simply use surface controllers in that situation.
These sorts of approaches allow you to use more of the MVC approach as well as the SOLID principles.
This recent article is a good read that can help give you ideas relating to SOLID principles.
That's a great question, but there is a flip side to remember.
It is completely possible to use Umbraco without any sort of compiler, such as Visual Studio, and without any C# code (I'm not referring to the C# razor you use).
You could install a clean Umbraco install and simply use the Umbraco back office to build your entire site. In this scenario, you can't create custom models or controllers.
So the "preferred" way to go is actually more based on what tools you have available to you, what you prefer.
There are things you definitely shouldn't do, but for the most part, it is more down to preference, experience, and complexity requirements.
Some of the decisions are development best practice in general (not language specific, but more OO principle specific).
I have a situation where a controller was handling an Api request, casting it to a custom ViewModel then passing it to a Template. The site owner tends to wait until code is in production to start QA which leads to making changes quickly in production. I moved the code that calls for Shopify products using their Api from the controller to the view that way I can make edits directly through the back office and it works great. I don't see this in particular mentioned as an anti-pattern, but I assumed I should move that code back to the controller as soon as possible. Now I am wondering...why? Will there be performance issues from doing it this way? I don't think security for things like ApiToken/ApiPassword is an issue because Razor is still server-side code that won't be seen by the public isn't that right? Thanks.
Logic in the Partial View vs Logic in the View vs Logic in a Controller
Hello people,
This is more of a question about the way you like doing things. I've been talking to other developers and there's a lot of way to do things.
Some people (like me) like throwing
in a partial view and then using the logic/variables in there (or some of it in a model, but not unless it's needed). Then rendering the actual view without any logic in it.
My boss for example, prefers:
and then just writing his data in his model and then doing something like
@Model.textIn the view. That, creates more work but gets you strongly typed models, but my actual question is:
Which one do you think is best, do you have any other ways and which one do you use?
hi Harry
I prefer the second way, this is easier for me and safer because it will show you an error if you are using wrong property alias
Thanks,
Alex
Hi Harry,
Like Alex, I too prefer the second option, for pretty much all of the same reasons.
As a brief note, if you're concerned about giving yourself additional work by creating strongly typed models for every document type in Umbraco (who really wants to do that eh?), then you should have a look at the ModelsBuilder package.
In a nutshell, this generates all of your models for you, saving you the hassle!
Useful Links:
https://our.umbraco.org/documentation/reference/templating/modelsbuilder/
https://24days.in/umbraco-cms/2016/getting-started-with-modelsbuilder/
Models Builder is now built into the Umbraco core, so there's no need to install a package if you're on a recent version, it should be running already.
I'm also curious how other people do this as well. Putting logic in the controller is clearly the most 'MVC' way to do things, but it also means doing a lot of route hijacking. I'm leaning towards this approach anyway, because it's supposed to make unit testing easier, but unfortunately unit testing in Umbraco is difficult either way.
Putting logic in the model doesn't seem like a good idea, it goes against the purpose of the model.
I guess a lot of it starts with depending on your skill level and experience.
However, I generally also look to use typed models in most situations. There are a few exceptions, such as conditional logic that is needed in layout files etc but with Models builder being part of Umbraco there is little reasons for most of your views not being type safe.
You don't need to route hijack for partial views you can just simply use surface controllers in that situation.
These sorts of approaches allow you to use more of the MVC approach as well as the SOLID principles.
This recent article is a good read that can help give you ideas relating to SOLID principles.
Why having the documentation as it is now, then? Why not tell devs how to use it the preferred way from the get go?
That's a great question, but there is a flip side to remember. It is completely possible to use Umbraco without any sort of compiler, such as Visual Studio, and without any C# code (I'm not referring to the C# razor you use).
You could install a clean Umbraco install and simply use the Umbraco back office to build your entire site. In this scenario, you can't create custom models or controllers.
So the "preferred" way to go is actually more based on what tools you have available to you, what you prefer.
There are things you definitely shouldn't do, but for the most part, it is more down to preference, experience, and complexity requirements.
Some of the decisions are development best practice in general (not language specific, but more OO principle specific).
Does that help? :-)
This is a great answer, thanks Nik.
I have a situation where a controller was handling an Api request, casting it to a custom ViewModel then passing it to a Template. The site owner tends to wait until code is in production to start QA which leads to making changes quickly in production. I moved the code that calls for Shopify products using their Api from the controller to the view that way I can make edits directly through the back office and it works great. I don't see this in particular mentioned as an anti-pattern, but I assumed I should move that code back to the controller as soon as possible. Now I am wondering...why? Will there be performance issues from doing it this way? I don't think security for things like ApiToken/ApiPassword is an issue because Razor is still server-side code that won't be seen by the public isn't that right? Thanks.
Here is some of the code in my view:
is working on a reply...