I have been working in an MVC project, and have seen both of these used. I was wondering what the difference between them is? Is it incorrect to use one over the other? My understanding is that I should be using Url.Content(), but VirtualPathUtility.ToAbsolute() seems to be working as well.
Url.Content() is an utility method part of MVC. Being there to uniformize and centralize utility classes I guess.
VirtualPathUtility.ToAbsolute() is a .NET Framework method. Maybe the MVC one is using it, we would have to check the source...
Hope the helps
If you are doing this conversion within a Controller, then I'd favour VirtualParthUtility.ToAbsolute() over Url.Content().
The benefit comes when you want to unit test the controller actions. Rather than call it directly though, I'd define an interface IPathUtilities, say, with one implementation using VirtualPathUtility methods for the live site, and another using some sort of mock when testing.
If you call VirtualPathUtility directly, then you won't be able to test the action method (you might have thought some clever mocking of HttpContext would get round this, but having tried this myself I couldn't find a way to do it).
Related
I am developing a simple project in MVC 6 and bit confused about whether to use DI or not.
I have a view that POSTs to an action - AddData(). Now inside AddData() action I instantiate a couple of classes, say Class1 and Class2, and then invoke their methods to get the job done.
Now my confusion is - In MVC 5 I used to create local instances of Class1 and Class2 inside the action and then call methods on them. This was without any DI.
In MVC 6 do I need to DI Class1 and Class2 in the controller? They are needed only in AddData() action. So is this situation good for DI or traditional local objects would be better?
Please clarify.
Dependency injection is a tool on your developer toolbox that should be used when needed. It will allow you to follow principles like SOLID, which will make your application design better, and it will be of invaluable help if you plan to do unit testing.
IMHO it is a great thing that dependency injection is now fully
integrated across the whole ASP 5 pipeline. This way, whenever you
need it, you won't have to fight the framework as the seam for your
code is already there.
But the fact that you can now use it, doesn't mean you should always use it. Use your judgement!
If you are writing some throwaway code or a very simple app, and you really think dependency injection is overkill, then don't use it. But at least you have taken a conscious decision!
Of course, the easier it is to apply DI, the more you might end up using it even for simple projects or throwaway code.
It is better to do so, so that in case you want to test your app later on, you can substitute with mocks, for instance. However, if you do not care about testing or if the app is really simple, then I don't see a reason against simply instantiating them inside the controller.
Without knowing what "Class1" and "Class2" are used for, this can't really be answered.
If they are models, then no, you wouldn't use DI.
If they are services/utilities, then yes, ideally use DI.
However - there's no difference in the architecture of DI between MVC5 and MVC6, so if you are not using DI in MVC5 then there's no reason to suddenly need to when you move to MVC6 unless you want to improve your practices.
Note there are some 'simple' IoC/DI frameworks that make this very easy and you can always use "poor man's DI" where you have a constructor with the class and one without, eg:
public Controller1()
{
this.class1 = new Class1();
}
public Controller1(Class1 class1)
{
this.class1 = class1;
}
(many people discourage this, but it's an option)
Right, so, if I was simply using Titanium, I could write:
var platino = require("co.lanica.platino");
And I'd be good to go. Since moving to Alloy, I don't know how to replicate the same line in the afforementioned MVC framework.
Do I add it under the global namespace? I already added the module in tiapp.xml, but I have no idea how to access it as a variable "platino".
The docs for Alloy are pretty sparse...any suggestions?
Require method is almost same in Alloy, you can use the require keyword in your js file and implement as in classic approach.
checkout the docs.
Relatively new convert to Symfony2 from ZF1.
I have Googled and cannot seem to find the answer. Just wondering if there is a way to not render a view from a controller action in Symfony2.
In a ZF controller I could use:
$this->_helper->viewRenderer->setNoRender(true);
What is the equivalent in Symfony2?
In Symfony nothing is rendered for you automatically. If you need to render something, you have to do it explicitly. If you don't want to render, just don't do it :) Simply return a response:
return new Response();
Only job of a Symfony controller is to return a response. Rendering a template actually creates a response as well.
Wanted to give my Opinion:
Just because there is a possibility to render(ControllerMethod,{ params}) in a template doesn't mean you have to use it.
Doing so leads almost always to a shitty architecture, the turning point where projects start to be hard to debug, since you are mixing a VIEW (Presentation layer) with a CONTROLLER, that in turn renders another VIEW. You get the point.
Then when you have an error in the ControllerMethod, and instead you get a template error, not so nice isn't it ?
I vouch for strong architecture in software projects. This cheap solutions, like using this commodities, lead to the start of the bad. And I suggest to avoid it as much as you can unless there is no other possible way. And certainly there is!
That is the reason to use MVC. To separate Code from Presentation layer, start mixing both, and your architecture will leak.
i am using EF4 and StructureMap in an asp.net web application. I am using the repository/unit of work patterns as detailed in this post. In the code, there is a line that delegates the setup of an ObjectContext in global.asax.
EntityUnitOfWorkFactory.SetObjectContext(() => new MyObjectContext());
On the web page code-behind, you can create a generic repository interface like so ...
IRepository<MyPocoObject> ds = ObjectFactory.GetInstance<IRepository<MyPocoObject>>();
My question is what is a good approach to refactoring this code so that I can use more than one ObjectContext and differentiate between them in the code-behind? Basically i have two databases/entity models in my application and need to query them both on the same page.
The Unit of Work is used to manage persistence across multiple repositories, not multiple object contexts.
You're not going to be able to persist changes across multiple contexts using a unit of work, as the UoW is simply implemented as a wrapper for a ObjectContext. Therefore, you'll need two unit of works.
Overall, things are going to get messy. You're going to have two OCs newed up and disposed each HTTP request, not to mention transaction management is going to be a nightmare.
Must you have two ObjectContexts? What is the reasoning for this? If it's for scalability, don't bother; it's going to be too painful for other things like your repository, unit of work and http scope management.
It's hard to provide good advice without seeing how you have your repositories set up.
Try creating wrapper classes for each object context, each implementing IUnitOfWork and a secondary unique interface (IEfSqlContext1, etc which represents one of your models/contexts).
Then you can inject whichever context you want.
As I said though, try and avoid having two EDMX/Contexts. It's more trouble than it's worth.
I am developing using TDD and ASP.Net MVC.
I have a custom ActionFilterAttribute which needs to be applied to certain controller actions and was wondering the best approach to this using TDD.
Currently the attribute itself has a
set of unit tests.
I develop the
controller action with tests as per
normal but ignore the case handled by
the attribute.
I add a unit test that
uses relfection to ensure the
attribute is applied (with correct
parameters) to the action.
If this a suitable way to go about it?
It sounds like it is.
What confuses You? Test that tests if attribute is applied? There is nothing bad with that. Testing actual constructions of code is very useful technique. You can force various conventions too with this approach like naming of classes in particular namespace, existence of public constructors w/o arguments, etc.