Asp.net MVC - How to achieve flexible modules to be used cross-project?

I´m not looking for code directly, but for some ideas how to solve my problem the best.

There is this asp.net mvc application I´m working on. It should be "highly modular" and many parts have to be reused across different projects.

Our current approach is using the Managed Extensibility Framework to import assemblies at runtime. These usually consist of everything necessary to work; models, views and controllers. Routes and navigation/main menu buttons are registered when being imported. This works so far; For example, I can simply copy the "news-column" assembly into any other project, include the MEF things, and "magically" the new project serves a news-feature accessible at /News/List.

However, the problem is, while in most cases the default view delivered within the assembly fits, I sometimes would like the imported controller to show up with a different view, displaying othe开发者_Go百科r fields in a custom layout. My current approach is to make the action methods in the modules virtual. If another project needs to render the list with a custom view, I simply override the list method, call the base method to fill the ViewData and then simply call whatever view I want. However, this somehow feels dirty and if anyone knows a better solution, I would really appreciate it.

Another problem I´m facing is that I may want an imported model to work with a different table. We are going with Fluent NHibernate where the target table is defined within the ClassMap - Table("News"). Mappings are imported like this:

foreach(Assembly assembly in assemblies)
  configuration.Mappings(m => m.FluentMappings.AddFromAssembly(assembly));

I could not figure out how to change the table of an imported Mapping, but I guess there is a simple way?

Thanks for at least reading this :)

I don't think overriding your controller actions should feel "dirty". In fact, I use base controller actions in a common library for things that can be easily abstracted like user authentication. On the flip side, authentication is usually very specific to the UI so I don't really bother creating reusable views.

I also create base controller classes within my apps to handle creating/disposing my EF context, etc.

You may want to consider abstracting your data access. Even though you are using NHibernate and your standard implementation uses a certain DB schema, you are running into a pretty classic problem of code reuse: putting too much specific logic in your reusable package. As a general rule, I try to keep any database specifics out of my reusable code. I use use POCO objects and interfaces so I can use any type of data source to create my objects. I may then have another assembly with a standard implementation using SQL server, EF, my preferred DB schema, etc. However, in the event I need to wire it up to something else I simple implement interface(s) in a new version.

Hope that answers your question.