I look more tutorial about MVC. But I didn't understand, people are using "BaseController" for what? In one project someone use it forcommunication between all controller. In other project someone use for get logs. Can you explain to me completely?
It is a very common practice for some developers to create a "BaseController" or really, a BaseAnything class to use for common functionality, and then derive other things from that BaseWhatever in order to reuse that functionality. This is just basic Object Oriented Programming techniques, and have nothing specific to do with MVC (other than the fact we're talking specifically about a BaseController in this instance).
There are some, and I happen to be among them, who believe that explicit Base classes are often a code smell, and are often severely abused as "catch alls". All too often, people put all kinds of stuff in these base classes for convenience, because it's easier than creating some other mechanism to share code or data in a better way.
I avoid Base classes unless absolutely necessary. I tend to prefer other methods to achieve the functionality that is often achieved this way (I call it lazy reuse). Examples of alternatives are:
Extension Methods
Html.Action methods
Attribute Frameworks, such as AOP
Dependency Injection
and many more..
You may create a base class with the best of intentions, and claim it will only be used for a very limited function... but before you know it, others that are developing in your project are stuffing all kinds of stuff in there.
My rules is, Just don't do it. Avoid creating a base class at all costs, unless there really is no other good way to do it.
*NOTE: I'm referring to concrete base classes used for the sole purpose of sharing implementation/data. Generic and abstract base classes are a bit of a different story, as are base classes used for Taxonomy (ie is-a relationships) and hierarchical purposes. In general, if you have called something FooBase or BaseFoo, it's probably of this type.
There are also other exceptions to this rule, such as when wrapping an untestable class for testing purposes, you often create a base class for this purpose, or in frameworks you sometimes deliberately build a base class that is intended to be inherited, but isn't generic or abstract. It's there to provide functionality to fit within the framework. But, these are not things you often have control over when using those frameworks.
this is not compulsory to use basecontroller in application but its like same you using master page for your all pages in application where you can keep your common functionality for your pages same applying here. while calling action method from each controller you require different common functionality like
exception handling
master page level settings
common custom authorization.
common custom caching
common model on master page level
so everytime if you call for different controller and its action, you need to regenerate same and this you can rebuild or handle through basecontroller.
Hope this will help to resolve your question.
Related
I am looking at the Orchard source and am looking for where the IOchardServices gets its concrete injected. I realize that all one has to do is specify the IOchardServices as a param in a controller constructor and it'll get injected, but I want to know where Autofac actually does it. I was looking at '/Orchard/Environment/OrchardStarter.cs' and there are many builder..... calls and so it looks like injection is occurring there; did a search in that file for IOchardServices and didn't find it.
The reason I'm interested in this is, I need to do property injection on aspx pages' codebehind since our team will only be able to slowly migrate over to Orchard CMS and we'll need to keep our existing pages as is, well without too much modification. I also assume that when we have our own custom interfaces we'll want to inject and will need to know the best place to do this.
The actual injection is done within Autofac itself, not in the Orchard code. The autofac-configuration is done by several autofac-modules within Orchard-modules.
When you want to migrate to Orchard, you can just start by first using Autofac without Orchard. Define logical interfaces and put the Autofac-configuration in application_start in your global.asax. See here and here for examples.
I'm working on a web application. One of my co-workers has written some asp.net forms pages. The page classes all inherit from BasePageClass, which of course inherits from the Page class. I wish to add some MVC controllers that I've been told need to use the same logic implemented in the BasePageClass. Ordinarily, I would want to inherit the functions in the BasePageClass in the controller classes, but this breaks the inheritance hierarchy.
What is the best practice for solving this problem?
If there is common functionality, I would suspect that this functionality should be separated out from the page/controller anyway. This is better OOP/D. Then both your controller base page and your System.Web.UI.Page base can both have properties returning classes that contain this common functionality.
(I've seen a lot of cases where stuff is crammed into the base page that should be elsewhere. Your need for this functionality to be in both the Pages and Controllers is likely just bringing this poor design to light, rather than being a problem in itself.)
Less likely to be what you want, but still a possibility:
You could also put your common functionality in a series of overloaded extension methods, where the first parameter is (a) System.Web.UI.Page and on the other overload (b) System.Web.Mvc.Controller.
Both your base page and base controller could implement a common interface, wrapping functionality stored in a common place.
Pull this functionality out altogether and do it as needed in your controler-logic and code-behinds.
I just want to know if anyone stores their helper classes or methods in a separate assembly and why...just for clean management of them? I've seen so many posts about using a helper folder inside your MVC project and that brings me back to the messy old days in ASP.NET where people were using an App_code folder instead of cleanly separating things out physically like this into its own project.
And likewise nobody doing real architecture is going to put models in some folder in your MVC web assembly. They would go in MyApp.DataLayer assembly or MyApp.Models or something like this.
Yes, but for reasons, which are common to other assemblies as well
Becomes easy to plug into any other project.(might need some editions).
Reusable
Easy to improve
Easy to refractor
As not part of a project, but project
itself, it is easy to document and easy for developers to understand
Clears out some of the mess
But for all that above, your assembly, when ready, should be a "job well done", other wise, it is better to keep the helper classes to where they belong.
We have some helpers in a separate project and some in the web project. I think you'll find that some of your helpers need to use abstractions that you've defined in your web project itself. And that will often force you to put those helpers into the web project, because it's not likely desirable to have some other project that has a reference to the web project. I don't consider it the same as using App_Code. These are files that are compiled at compile time inside your IDE, with no special "magic" that gets applied to App_Code.
I use projects to separate out the different layers in my web or form apps. It allows me to respect the business rules better. Also I find it easier to track down where I need to go if I want to make a change.
But I have seen people use folders that label the layers in the solution but I think that is a little messy.
Yes, because they are part of the Business Layer. Two big payoffs:
Reusability
Testability
Keep in mind that your utility functions and helper classes are likely to be some of the most heavily used components of your entire system. Without full BICEP testing, you run a truly unacceptable risk.
Most helpers that I create are usually layer specific so I tend to keep them with the assembly the base assembly that needs them. I don't see a reason to add in another project to store a large number of specific helper classes.
I'm currently implementing a project using asp.net, c# and the MVP (Model-View-Presenter) pattern. The main purpose of this solution is to deliver a graph to the consumer, to be used by a variety of systems. It is basically a custom graph server.
The view page in this particular case has an MSChart control on it, which has to be dynamically populated and configured based on parameters in the QueryString. This can be as diverse as totally different types of data sets, display modes and so on, using a lot of the properties of the chart control.
Many of these properties are again of types which are particular to the chart control and would require the same dependencies as the chart control itself if they are to be set by the presenter.
I'm trying to figure out the best way to expose the properties to the presenter so it can work its magic.
Should I:
Just expose the whole chart object and live with a system.web type dependency in the presenter project?
Make accessor and translation properties for all of the chart control properties so that I don't have the dependency, but add lots of complexity?
Other, that I haven't thought of?
To me it seems that it would be against the MVP pattern to bubble a display control up into the presenter, but it seems that trying to map all the properties to DTOs or similar would be a lot of work that would add a lot of complexity, and while the solution would be somewhat more loosely coupled, I'm not sure the gain would be worth it in this case.
How would you implement something like this, given MVP?
While doing some more research on this topic, I found the following blog post on adding a Presenter Model to handle complex view controls, to map between the view and the presenter. It actually made a lot of sense to me, and it's an idea I think I'm going to follow up on and try.
http://mikewagg.blogspot.com/2009/01/managing-complexity-with-mvp-and.html
In fact, Martin Fowler has written on this as well:
http://martinfowler.com/eaaDev/PresentationModel.html
Check out Automapper. Makes translating from a Business Object to a View Model almost effortless. The general idea is your View Model should only have primitive system types if possible to avoid formatting/conditionals in your view.
I am a AS3 novice learning PureMVC and want to write code following best practices so that any other AS3 developer can pick up my code and easily understand what I did, I am tempted to do stuff as I would in JavaScript or Asp.Net/C#, but I have a feeling that might not be the best approach.
Thoughts? Links?
Using reverse domain folder structure is common from the Flex code I have seen. ie:
com/mydomain/myproject/view ... model, business, controller (this would make it easy for me to understand your code)
More: http://blog.tsclausing.com/post/11
ASDoc is a tool that creates very pretty HTML documentation from code comments automatically:
http://livedocs.adobe.com/flex/201/html/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Book_Parts&file=asdoc_127_1.html
You may be beyond this point but I have used Cairngorm (MVC) and it was well documented:
http://opensource.adobe.com/wiki/display/cairngorm/Cairngorm
Code Example
This is the Cairngorm store which is the standard Cairngorm example:
http://cairngormdocs.org/blog/?p=17
I found that reading through the docs helped me get a clear definition of each of the parts to PureMVC. On top of that I downloaded the source for the demos and added them in Flex Builder so I could look through them easily and see how they were constructed to get an idea of how I should construct my project.
One thing you have to remember is that you can do things any way you want, but to make using the framework worthwhile you should stick to the structure and way of doing things that it suggests. For example you could give your view a reference to the facade and have it get information from Proxies etc. But you should keep the view decoupled from the framework and just have it dispatch events and have a Mediator deal with the facade.