I have a website that runs with AD authentication for all users. I am adding a module to the website that lives as a tab on the main page. There is a new thought that the latest tab can be its own web url/website. But without any AD authentication, open to public. Since everything is originally built in one code base until now, is it easy to create a new website just for one tab content. The tab/module has its own controller, its own views, but has some shared references/service layer code. Whats the best way to approach such a situation. The new tab that will turn into a new url/website will be hosted on a separate server due to security issues.
Are two code bases needed, one with old website code and one with just the new module addition code? or can we just do this two websites
with single code base?
If I am separating the new module code into a new code base for the new server, I am guessing I need to copy the original project and
prune away any unwanted old modules/controller/views etc.. is this the
recommended approach?
In general, how does someone approach this kind of situation, specially with the differences in the way the two parts authenitcate (one with AD and one with no authentication)
Why not seprate these modules with ASP.NET MVC Areas. Have your exising code in one area and the new public stuff in second area. You can use the common service layer code in both area's controllers now as it(the areas) belongs to the same UI project.
If the module doesn't require authentication, it'll live fine just on its own and you can include it in the site that does require authentication.
But what I get from your question, the module isn't that modular, since it depends on modules that do require authentication. So alter the dependencies so that they too stand on their own.
Related
I have a standard MVC 5 project created from the VS Template. Now I want to move the Account related controller and views to different project so it becomes a module. (That way it can easily be include/excluded from the site.)
I have been able to put the Controller in another project and reference the project, but the account views are not located at runtime.
How do I tell the View Engine to look in the other project for the account views?
After a lot of working with this, it seems that having views in a different DLL may not be the best pattern. First, while it can be done, it requires some extra plumbing. Second, it seems to violate the MVC pattern in that now you have two MVC patterns working side by side. What has worked for me is simply moving the Model part to a different dll. In other words, the plugin becomes a Model provider which is simply used by the Controller and then combined with the view. This is very easy to work with, requires nothing special, and yet separates the responsibilities.
I am trying to find the best way to layout my MVC 3 project. When searching online I came across a suggestion that basically said right click on project and add area. What this did was create an area folder with same controller/view/model structure in the same project. This is not what I want. I want the flexibility of having separate projects. I will keep only the views in the main web project. Everything else in a separate project.
Towards that attempt I created a separate project for my controllers. Now I am stuck with pointing a controller action to a view. In all the online examples it was right click and add view. This being a class library project I don't have that flexibility. Where am I going wrong?
All examples that I have found including the ones I have gone through on Asp.net basically explain how to create study applications, which is only good for learning purposes. A large commercial application can't possibly have all the views/models/controllers in one project. Or is that the way it is supposed to go in MVC? I am not sure if doing everything with mouse clicks is also a good idea. In the webforms world also there were a lot of study-for-beginners applications that used mouse clicks to create basic CRUD applications, but in real commercial projects, we never used those methods.
What are your thoughts, guidance on this?
Thanks for your time...
MVC is based on a convention; the convention is you put all the views on /views, the models in /models and the controllers in /controllers. You can change the convention but it will not make your life easier.
From a conceptual point of view this does make sense. If you keep all domain logic and data access in separate projects all you are left with is the web related stuff, your controllers, view models and views. That's your MVC project.
Note that if you want to split off parts into separate projects you may find portable areas useful.
I don't see why you can't use the built in generators as a base for your views and controllers? Nothing says that you have to leave them as generated. I personally thinks that's it's really nice to get a base generated for me (with mouse clicks).
The MVC project is just a UI layer. It's madness to put logic in it for large scale applications. It's therefore usually fine to have one project for all the UI. It actually makes it easier to get an overview of the UI.
That said, there are ways to get a plugin based solution where you can move the controllers (, models and views) to class libraries. But it's not easy.
You need to create a virtual path provider (to find the views)
Make all views embedded
Modify the project file to get the "Add view" dialog etc.
Use areas (makes it easier)
Tell the BuildManager that your plugin DLL exists.
You also need to modify the virtual path provider to access the views from your plugin folders if you want to be able to modify the views during runtime in visual studio. Any change would otherwise require a rebuild of the plugin DLL.
Update
Video for MVC2 (MVC3 areas works the same): http://www.asp.net/mvc/videos/mvc-2/how-do-i/aspnet-mvc-2-areas
Do note that that video is for areas in the same project. Having areas in separate class libraries are more complex. The easiest solution is to use the portable areas as suggested by someone else.
Why keep only your views in the 'main web project' - I think you are missing the point with MVC.
It's the controllers that are your 'main web' part. They are what your users request and post back to, not the view.
The view is only there to provide a means to layout HTML for the controller to push to the browser.
The Models which I think should really be ViewModels, are there to provide substance (i.e. real data) for your views.
So you can see that the MVC layout really wants all three of these to be grouped sensibly together. Controllers interact with your user, get the view (the layout) and populate it with your ViewModel/Model (the data). This is your user interface, all three parts of MVC (if you go with the ViewModel anyway) are only for UI.
Where the data comes from, your real models and whatever you want to do with it can easily reside in a dll somewhere or on the other side of a set of web services or whatever.
I'm working on a project in Grails 2.0.RC1 and I'd like to be able to save the scaffolded controllers and views for my domain objects to have as a "low-level", developer only access to still tinker with things while being able to develop the production version of the views and controllers (with similar names, especially for controllers). I'd like to preserve them as-is, so I can re-generate them as I make updates to the domain layer, so just moving them is most likely not going to work.
I'm hoping there's a way to do some UrlMapping magic that would let me have requests for "/mgr/book" go to the scaffolded Book controller, but "/book" would go to my production controller. I can't find anything in the docs about how to have mappings for specific groups of controllers (without specifying each controller by name versus a $controller notation).
My other thought is to turn my domain layer into a plug-in and then create a separate project that would be just for the scaffolded views. This would be easier to remove before going to production, but also seems like more work, and raises the issue of running two grails apps at the same time on the same box.
I would advance you to go like your last idea. This is also my common approach:
Create an embeddable plugin for your domain model and common services. This also includes common plugins, like spring security and stuff. This will also reduce your dependency resolution time for the main-app btw.
Create an embeddable plugin for your scaffolded views. Change the template of the scaffolded controllers to require authentication and admin-group.
Your main-app uses both plugins.
This keeps your main-app clean and simple and you can still regenerate all your scaffolded views & controllers as you wish. And at least Eclipse STS hot-deployment will still work!
However there is no simple solution for seperating your scaffolded controllers URL-wise yet.
If you are using Spring Security, you should be able to use an InterceptUrlMap or RequestMap Instances to secure the controller URLs.
If your scaffold controllers are only used for scaffolding (and don't have other actions), then you should be able to use basic Secured annotations to secure the entire controller.
Then you can use the scaffolding like normal, protected behind a login.
Other security frameworks may provide similar access control.
I have a solution which contains 2 MVC Website Applications (Website & Website Admin System). As I am progressing with the build there is a lot of common code especially in my View Models, HtmlHelpers etc. Is it good practice in MVC to treat these two sites as separate entities and keep code in one site specific to that site and manually copy code across to second site? Or is there a practice to share this common code across web apps?
It is just natural for me to refactor common code when I see it? However I am not so sure how this works within an MVC environment. Any suggestions or comments welcome.
You can create a class library project and push that code to that project. Then have both website projects reference that DLL. I believe views are about the only thing in MVC that you can't do that with. I believe you can do it with controllers too, but I haven't tried it.
If your sites are sharing many ViewModels and HtmlHelpers I'd take a step back and examine why they are two separate sites. Is the second one an Admin area of the first site, or is it a completely separate entity altogether? If the first, I'd probably have everything in one site. If the second, I'd do as Brian Ball suggested and create a library project that the two sites share.
We will be developing a very large vertical market web application, and are leaning toward the MVC approach.
It will have 1 Master Page common to all views in the application.
The master will provide a navigation/search framework for the entire application
that will allow users to search and select entities and then navigate to a function to perform.
The database model will have 700 to 1000 tables.
The application will have hundreds of controllers.
Controllers and their views could be grouped together into one of the many (20-50) subsystems in the application.
(We are looking at an areas approach to aide in organization).
We want to be able to deliver enhancements/updates in small functional pieces.
These might me a new function, a bug fix, customer dependent functionality, or optional modules separately purchased by the enduser.
We spent too many years developing/supporting and delivering one large windows vb app exe.
We would like to take another approach.
Management does not want to deliver one large application. They want to be able to deliver
small incremental pieces when necessary.
We may want to create a deliverable that contains one controller, and only a couple views, and a portion of the model.
To deliver it, we want to copy a dll to a bin folder, and create a View folder and copy in the new view(s). As simple as possible!
I have spent many days researching this and haven't come up with a clear path to proceed.
(Every tutorial and article I found assumed a single project.)
How do we structure the application to accomplish this?
How do we break up the application into separate projects/assemblies to do this?
Can you build a base project that contains the Master Page, authentication, and Global routing,
and then reference this in each of the potentially hundreds of other projects for each of the modules?
In development, does each sub-project need to contain the entire base project, or just the shared views folder, Global routing,
and web.config and a reference to the base project dll?
Any detail documents explaining this approach?
Any development/Testing issues?
Thanks for all input, we have to get this going soon.
Update:
Followed the example here link text
It is a great starting point!
I think this is exactly the case where DLR would help. Your Controllers and Views can be stored as scripts in the database. It will be very easy to deliver your application as a set of "small functional pieces". You could start from reading Haacked - Scripting ASP.NET MVC Views Stored In The Database
Absolutely, break the project up into sub-projects / modules containing your controllers. You can use an IoC container like Unity, Spring.Net, or Castle Windsor to locate your appropriate controllers in the child projects.
Implement your own IControllerFactory to do the Controller lookups in the IoC container based on the controller name passed to it. You're looking to put in place an IControllerFactory.CreateController method that looks something like:
public IController CreateController(RequestContext requestContext, string controllerName)
{
return (IController)IoCContainer.GetObjectByName(controllerName);
}
Then you should be able to simply modify your IoC configuration file to define your new controllers as they are deployed.
Google for MVC with MEF. There is an example by one of the MEF team that will suit your needs exactly.