I'm in the research/planning phase of a project (.Net c#, mvc or silverlight). It's a web project that offers certain services bundled into packages. The client can sign up for one of the different packages.
I'm looking for any suggestions on which architecture/framework to use for this kind of project. I want the ability to load or unload modules depending on the package. I also want to be able to enable and disable features within the packages themselves.
The modules have to be highly portable and plug-able into different clients. I know there are MEF and Prism but I haven't really worked with both. I also read about MVC and Areas. I would rather design everything from scratch and not depend on a third party if the task is simple enough. I just don't know where or how to start.
I appreciate the suggestions.
MG
You can forget about unloading. You have to use seperate appdomsins to be able to unload modules. And that's nothing that I would ever try with a ASP.NET website.
You have to get used to the thought that all modules are loaded at all times. You can use role based security to control if a user can use a module or not (one or more roles per plugin).
As for loading things dynamically: I've written an article about how you can create a plugin system using my Griffin.MvcContrib: http://www.codeproject.com/Articles/386674/ASP-NET-MVC-3-plug-in-architecture-using-Griffin-M
Related
Building large web applications in one massive ASP.NET MVC project is not easy to manage, especially with multiple developers, as you know Controllers, Models, and business logic can all be put into separate packages.
but what I want is a little different than deployment, suppose several developers are working on a ASP.Net MVC project in presentation layer so what I want is that each developer can be able to work in her/his zone and at the end give me a package which is contains controller,model,views and UI staff such as CSS,JS,pics and etc...) then I patch it into the main project without any manipulate main project, so from what I have googled there are some plug-gable architecture to do this
but as you know each of them have it's pros and cons but I am hesitant to choose better,
there are some of them listed below:
1- MvcContrib
2- MEFContrib
3- Microsoft Unity
1- I think in Unity dependency injection there is a problem, after building package we should define all interface in main project(I think UnityContainer) so it is a problem because you must change the main project and rebuild it
2- In Mef and MVCContrib there are some other problem such as memory leak and they are embed all CSS and UI staff to a dll, so think a about if we want to change one of that css file then developer should rebuild all the package.
so what you think about the above problem or is there solution to make they easier to use or I am going wrong because I am newbie to use them.
which one is better according to their pros and cons.
Thanks in advance.
I am converting a .NET 2.0 Winforms applications to ASP.NET MVC3. The Winforms solution uses several projects for business logic, and the MVC application includes these projects. The projects are also used by a variety of Windows console applications.
The problem is that these projects use System.Windows.Forms.Application.StartupPath to find files they use, whereas for web development System.Web.HttpRunTime.AppDomainAppPath is used.
I would prefer that both solutions use the same projects and that these projects are modified as little as possible as they are large, old, and relatively undocumented. What is the correct way to address this issue?
Right now I am thinking that I would create a new configuration with each project that would define WEB, and then use #if/#else statements to include the correct depedency and to define the return of the getPath() method.
Before you start plaguing your code with preprocessors, you should consider creating an interface IApplicationConfigurator or IApplicationStarter
public interface IApplicationStarter
{
string GetPath();
}
And inject it with a MvcApplicationStarter or a WinformsApplicationStarter depending on your application. You can then have your project libraries have a dependency on the IApplicationStarter interface. It should require minimal implementation on the projects, and you can reuse the pattern for other common dependencies. Look into dependency injection frameworks as it takes this approach into the next level.
This is what class libraries are for. Create a class library project, move all the common bits there, and then have a separate WinForms and MVC project that both reference your class library.
I am building several different asp.net mvc 3 web projects all under one solution. I'd like to be able to utilize a few views across all of those projects as they're all going to be displaying the same thing on 2 or 3 different pages (with some custom stuff plugged in per the application).
Is this possible to do?
Only thing I can think of is to compile your cshtml into a separate assembly (assuming you are using RAZOR). See here.
Generally speaking I've not seen many examples of multi project ASP.NET MVC solutions. Because it kinda doesn't make sense. It complicates things, it disregards areas, which could possibly be used to get the same kind of experience but are far better option that multiple MVC projects. Then there's the question whether the 3 projects have so much in common that they really should all be in one solution. What kind of MVC applications do you actually have? What do they do? Most sample solutions online are single MVC project and multiple class library projects.
Now to the actual question..I recently found myself doing something similar, actually I didn't have multiple projects in one solution but I had different standalone projects that would all benefit from using the Views from one single, we could say the "master" project. I ended up creating Nuget package for it. I actually also injected other stuff into the package (scripts, styles, images, etc) but you could use it for Views only too. Then you just add the package to the next project and it inserts the files in the package into destination project. What I'm trying to say is, your package doesn't necessarily have to contain code.
I won't go into details here but you should look into it.
Im currently developing an application with two web projects (MVC):
Frontend
Backend
These two are going to have almost the same layout (few minor changes). Therefore I thought about creating a MasterPage, they can share. But since it's two projects in two different locations, where should I put the masterpage, images and javascript?
The images and javascript (static stuff), could be placed on a CDN.
But how 'bout the ASP.NET specific stuff? Any suggestions? Any help appreciated!
A MasterPage is a UserControl under the hood, so any method of sharing UserControls would work for MasterPages. Unfortunately this isn't that great of an experience in ASP.NET as the BuildManager (what compiles and connects the app paths to classes during build-time) only recognizes & processes files within the current project.
Sharing code-behind, or base classes is easy and works well. It is the design surface (.master, .ascx, .aspx) that doesn't have a lot of ability to be shared. You can use a deployment project to compile a web app project into an Assembly that can be referenced, but you will still need some design files in your actual project.
This might also be of help:
ScottGu: Creating and Using User Control Libraries
SO: How do I share user controls between web applications in ASP.NET?
It's possible to include an existing file from another project in a new project. You can do that. So just put it in one project and include it in the other.
Alternatively, you can create a 'core' library, and put things in there, but that doesn't 'play' well with controls and so on, so I'd recommend the first approach.
The ASP.NET team released the script combining feature in 3.5 SP1 as detailed here http://www.asp.net/Learn/3.5-SP1/video-296.aspx. Is there a similar feature already for the MVC framework? If not, is this in scope or is it possible to somehow leverage the webforms capability in MVC? I see this site uses a custom jquery.package.master which, I assume, they have rolled themselves (maybe into the build cycle, however it is not all minified therefore I think they have manually appended the scripts together rather than some automated minify & combine task). Would be interested in any ideas how to accomplish this in MVC but I dont want to begin rolling any of my own functionality in case I will be duplicating work in progress.
Here's what I do, in case it's helpful.
In my postbuild I call a command line version of Dean Edwards's Packer. It combines the scripts and packs them for me.
For now though, I keep all of my stuff seperate and use a Helper method to include my scripts, and if the debug flag is not present it will include the packed versions, otherwise it includes the unpacked.
Another option is in the Telerik Native UI Extensions for MVC (free library and open source), called ScriptRegistar. It will combine and compress javascript for you, and is fairly feature rich. There is also a class for doing the same to css as well.
I am using this to combine +20 javascript files into one file which is downloaded by the browser.
http://www.telerik.com/products/aspnet-mvc.aspx and you can get it via NuGet.
Every day there is a different way of doing things and the techniques changes.
At this time there is a very good Nuget Package released in CodePlex.
Combres - WebForm & MVC Client-side Resource Combine Library
http://combres.codeplex.com/
http://weblogs.asp.net/gunnarpeipman/archive/2009/07/04/asp-net-mvc-how-to-combine-scripts-and-other-resources.aspx