I've searched (google and SO) about this topic and couldn't find a thorough answer to my question(s).
I'm building an ASP.NET MVC 2 application that will be distributed to other people (with source code). These people will need to create modules/plugins that use the application's base.
The base is a simple ASP.NET MVC Application with Linq-To-Sql file, repositories, authorization/membership.
Is it possible to create a plugin that would work by simply adding a .DLL file in a folder?
Right now, you can create a "plugin" by opening the source project of the base application, creating a few controllers/views that do somethings, using the base application's authorization/membership and repositories. You would also be required to edit the Linq-to-Sql file and add in any tables that you need.
However, to "install" this plugin, I would need to copy the controllers/views for this plugin into my base application and edit the Linq-to-Sql class to include the tables necessary for this plugin, then build the solution. Is there a simpler method?
I read of .DLL plugins, but how would someone build a plugin like this starting from the base application.
If the 'plugin' creates tables with foreign keys of the "User" table in the main application, how does one separate those tables/relationships in a separate file and have the base application recognize those relationships?
As you can tell, I'm asking multiple questions that are kind of all over the place. This is a new topic/issue for me and I have no idea where to start. Theme mere concept of having my application interact with a separate .DLL file is foreign to me.
Any help/links would be greatly apprecaited.
Does this answer the same question: Plug-in architecture for ASP.NET MVC?
I think this could be applied to mvc too: http://msdn.microsoft.com/en-us/library/ms972962.aspx
Related
I want to create a class library for an MVC 4 web application. Every search I've tried has returned plenty of references that merely mention creating one, or the importance of doing so, but not specifics of how.
My first assumption was a template would be under Web in the Visual Studio New Project dialog, but no. I was unsure if I was to use the Class Library template under Windows, but did.
I want to include things like some data access (e.g., DbContext), but while Intellisense sees the System.Data.Entity namespace, there are no classes available. I guess I need some additional references, but no idea which ones. Looking at the references in my main MVC project, at lot of them are pointing to the Packages folder. I'm unsure if I should be doing the same.
In short, I'm looking for instructions on how to create a class library for MVC in Visual Studio, including the necessary references for EF, Razor and whatever else.
you used the correct template - a simple class library is all you need.
then in the MVC web project just add a reference to the class library project
Use NuGet to add references to the pieces of functionality, like EF and System.Web.MVC, that you need in your class library or libraries.
A data access project to handle persistence and a class library to hold HTML Helpers that you might want to reuse both make some sense. Razor views if you're using the RazorEngine rendering stack can also be interesting to be able to test.
You are right to use the Class Library template in visual studio for your needs. You can add all of the references you need through NuGet (such as Razor, EF, and so on) and by Right clicking on references in the Solution Explorer and picking and choosing what you need.
Remember when using multiple projects that you add references between projects too! (for example your Web App project needs to know about your Data Repository Project)
I'm just starting to work with MVC and trying to understand the best practices behind designing an application. In the WebForms world, I typically just created a Classes folder where I stored all of my *.cs files. However, because of the way that MVC uses the folder structure to create different namespaces, I'm not sure that's the right thing to do any more. I can't seem to find any guidance from Microsoft on this topic, so I'm hoping someone here can oint me in the right direction.
Is there a right way to organize files in an MVC app? And, more generally, is there an authoritative place to look for this kind of best practice guidance?
Here's a sample folders structure:
Controllers
Models
ViewModels
Mappers
Views
Repositories
Services
Validators
...
Obviously those layers could be split between different assemblies.
You may also take a look at a sample MVC project structure I wrote.
The MVC namespaces don't dictate where your classes should be kept. However, it makes lot of sense if you store them in proper locations as per their category. e.g. if it's a controller class, you will store it in Controllers folder. If it's a ViewModel, you would store it in a ViewModel folder.
Having said that, I believe what you meant by classes were entities that you use for your business logic. If that's the case, you might want to store them in a seperate class library if you application is big enough and you are creating Plain Old CLR Objects (POCOs) by hand. This is the same as you did in the webforms world.
In case it's not a big application or you are using ORM generated entities like those generated by LINQ or Entity Framework, and not explicitly creating them, you might want to include the .DBML (LINQ) or .EDMX (Entity Framework) files in the Model folder. The Entities will then be inside the auto generated designer files in the Model folder.
Hope this helps.
The only special folder in Mvc is the Views folder (and also the Areas folder but that's an advanced topic) where the frameworks locates view files. Your source code files can go into arbitrary locations. However, the structure that Darin listed is a useful convention that helps different developers working on the same project quickly located what they are looking for
You can also start with a new project using the Empty project template (it's not actually empty) and it will create the basic recomended folder structure for you.
Does any one have any idea about multiproject area support in asp.net mvc 3? As it was degraded to future status in mvc 2. If it is still not included then should we look forward for ASP.Net MVC Portable Areas via MvcContrib. Can you share your expreriences?
What are the recommended way for managing a large application? I read about MEF. In what scenarios MEF is recommended?
I'm the development lead on ASP.NET MVC at Microsoft.
There are no plans to include multi-project areas in ASP.NET MVC 3. However, it's definitely an area that we plan to revisit in the future.
In the meantime MvcContrib's solutions are probably the best bet. The MVC Futures download still includes an old (and perhaps only semi-functional) version of the original multi-project areas feature. Because the full source code for it is also available, you might be able to construct a solution that is customized to your needs.
I need to have the same structure so I have figured out how to have areas as separate projects. There are no code changes needed, just a bit of configuration work you have to do.
I am going to create a blog entry on this but here are the basic steps.
Let's assume you have a single MVC application project and this will be your "shell" app.
right click on the shell project and "Add Area...". Type in the area name. This will create an Areas folder with your area in it. (This is not 100% needed but you do need the "Areas" folder and you can steal the XXXXAreaRegistration class for your application.)
Create a new MVC3 empty project in your solution to match your area. Move the XXXXAreaRegistration.cs file to the new project and adjust the namespace as applicable.
Delete the folder under the areas folder that the template wizard added.
Modify the web.config of the new project and take out the connection strings and the authentication, membership, profile, rolemanger sections. You don't really need the web.config but the razor intellisense doesn't work without it.
Create a virtual directory in the "Areas" folder of the shell project with the name of your area as the alias and point it to your "area" project. You will need to use IIS or IIS Express for this. I use IIS. In IIS express you have to modify the config file. I think ScottGu had a blog entry on how to do this.
Create a post-build event on your "area" project to copy the dll to the "shell" projects bin folder. My build event is: copy $(TargetDir)\$(TargetFileName) $(SolutionDir)\ShellProjectName\bin\$(TargetFileName)
In the shell web.config add the "area" project into the System.Web/Assemblies section.
Instead of 6/7 you can just reference the "area" project with the "shell" project and it works just as well. But, then you have to deploy all the "area" dlls every time. I am probably going to do some type of probing code to add the "area" assemblies to the app domain at app start up using reflection or MEF.
You might also want to edit your routing and add the namespace filter to it in both the shell app and the area app. This way you don't have to worry about duplicate controller names conflicting between the sell app and the area apps.
That's about it. Once I get a formal blog entry posted up I will try to remember to add a link to it here.
I blogged how I am doing this at http://bob.archer.net/content/aspnet-mvc3-areas-separate-projects if anyone is interested.
I'm developing MVC application where I currently have 3 projects in solution.
Core (it is supposed to be for Repositories, Business Classes, Models, HttpModules, HttpFilters, Settings, etc.)
Data access (Data provider, for instance SqlDataProvider for working with SQL Server datastore - implements Repository interfaces, XmlDataProvider - also implements Repository interfaces but for local XML files as datastore)
ASP.NET MVC project (all the typical stuff, UI, controllers, content, scripts, resources and helpers).
I have no Models in my ASP.NET MVC project. I've just run into a problem because of that coz I want to use the new DataAnnotation feature in MVC 2 on my Business class, which are, as said in Core, however I want to be able to localize the error messages. This where my problem starts. I cannot use my Resources from MVC project in Core. The MVC project references Core and it cannot be vice-versa.
My options as I see them are:
1) Move Resources out but this would require correcting a whole bunch of Views and Controllers where I reference them,
2) Make a complete restructure of my app
What are your thoughts on this? Also, Should I just move everything business related into Models folder in MVC project?? Does it even make any sense to have it structured like that, because we can just make subfolders for everything under MVC project? The whole Core library is not intended to ever be used for anything else, so there actually no point of compiling it to a separate DLL.
Suggestions appreciated.
Throw it all into one big .csproj boat and use folders to separate things. Its much easier to navigate folders than separate projects. You won't have to fight namespaces all the time and everything is right were you expect it. You completely eliminate any .sln kung fu when things aren't int he right location or assemblies need to be referenced and you can spend more time coding rather than moving .sln bits around.
Some people say it makes it harder to "swap out an implementation" which is baloney. Swapping the contents of a folder is just as easy as swapping the project.
The MVC source is what made me fond of this approach. They flatten everything out and its really easy to swim around their source code.
I would like to use a WebSite project instead of a Web Application project for an MVC project.
What is the best way to accomplish this and are there signifigant problems that I might run into?
(as a side note, my reasoning for wanting this is because I have graphic designers who put files into SVN but they don't get added to the "project" and don't show up on deployment or deployment testing. My thought was that switching to a Web Site project might prevent this)
You don't need to do anything special if you are not using CodeBehind files (if you're using them, it'll be more complex but anyway, it's an MVC app. If you're using them, don't!). Just take an MVC Web app project and put all source files (*.cs) under App_Code directory of the Web site. That said, I fail to see any advantage for it.
The application project allows you to use the Models folder to embed classes into. This would then be compiled for that web project. A web site does not provide for this directly. It would require that you use an assembly project to maintain all of your classes. Rather than converting from one project type to another (which I am not sure how you wold go about doing that) you can simply attach an assembly project to your web application and not store any classes in the model folder of your application.
Having said this, you should keep your web project as an application as there usually are view specific classes that are required such as a your view model classes that belong in the web project.