i want to develop a simple CMS.
i want to add the ability to add modules to the CMS.
what need to be the architecture for
such a CMS?
a solution and then a mvc project
for the site and another for the
admin? or one project with area for
the admin?
in mvc each of my modules will have a controller,model and views. if i will put all in one project, then i will mix of all module ,each module will be in 3 folders (controller,model and views).
how i need to arrange them so my code will be nice and clean?
Since you are only separating by type of user, you can surely (and easily) include in one project. all of your Admin controllers should have [Authorize(Roles="Admin")] on them to limit them only for the admin. Mixing them is fine, other applications mix user roles in an application on a regular basis, just limit the difference by security (and dont use url restrictions in your web.config - use the [Authorize] attribute on your controllers instead!!
If you expect the differences in both applications to be huge then you can separate into another project, but I'm imagining you can get very good reuse by including them in the same project.
How to architect this is a very very broad question. For a basic project some include everything all in one project. I prefer to break out all my models and data access code into a separate project and try to code to interfaces as much as possible for unit testing purposes. I think that is all a bit beyond the scope of the posting here though. To start - work with the mentioned attribute and I think you will develop. Start unit testing early and I think that will help steer you into the right direction. Also read up on dependency injectiom , unit, ninject, etc for ways to dynamically bind to your implementation classes as this makes your unit test go quite a bit smoother as well.
Related
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.
we are building a new web application using Microsoft ASP.NET MVC2 and Entity Framework 4. Although I am sure there is not one right answer to my question, we are struggling to agree a VS2010 solution structure.
The application will use SQL Server 2008 with a possible future Azure cloud version. We are using EF4 with T4 POCOs (model-first) and accessing a number of third-party web-services. We will also be connecting to a number of external messaging systems. UI is based on standard ASP.NET (MVC) with jQuery. In future we may deliver a Silverlight/WPF version - as well as mobile.
So put simply, we start with a VS2010 blank solution - then what? I have suggested 4 folders Data (the EF edmx file etc), Domain (entities, repositories), Services (web-services access), Presentation (web ui etc). However under Presentation, creating the ASP.NET MVC2 project obviously creates it's own Models folder etc and it just doesn't seem to fit too well in this proposed structure. I'm also missing a business layer (or does this sit in the domain?).
Again I am sure there is no one right way to do it, but I'd really appreciate your views on this.
Thanks
Jfar is correct. It doesn't matter at this point what structure your solution takes. You'll have plenty of time to rearrange the solution later. I've done many small MVC applications and one large one and I'm still evolving how I prefer to structure the projects/solutions.
As far as structuring and MVC project, the only folder that really matters is Views. I have started to break away from the /Controllers and /ViewModels folder structure and grouping things by domain concept. If Student is one of your domain concepts, I'd have a Students folder in the domain project, in the MVC Views folder, in the services project, etc. All the domain classes, view models, controllers, etc would go under the same folder name (in different projects). That way you always know directly where to go to if you want to modify Student related code.
Also, we have a Web project that hosts the views and a separate class library project that contains the controllers. Most of my solutions have 12-30 projects.
I believe you are right to consider the project structure (and namespaces) at this early stage. Although jfar's point is well made how often are you given the luxury to restructure your projects and namespaces before your first release? Even something as you suggest is better than throwing everything into the same project - surely?
Wanted to add - it's not so important how You organize Your folders/solution, it is important how You organize Your code.
So - If Your app won't be properly layered using fancy techniques like dependency inversion, won't be neat and testable - it won't matter if You put stinky code in one or hundred folders. You won't be able to migrate from sql to Azure, from mvc to silverlight.
What makes sense to you and your team?
What folder the code is in means nothing ( besides minor namespace generation ) and can be easily changed by dragging and dropping.
Right now organization barely matters, you have so little files its easy to browse around the slution. Once your 6 months in and you have 1000s of files thats when you'll need to start thinking about organisation.
With my own personal projects I dump everything into a single project, at work I have a 17 project solution and 50 folders. Code is code.
I am a Java Developer making the transition to the C# world. I've gotten a pretty good handle on ASP.NET MVC (and can compare/contrast it to the concepts I learned for Struts).
However, I'm looking for advice on how to structure my project. Currently, I have two solutions in the project: the MVC Web Application and a ClassLibrary section.
The application uses a tiered architecture: Controllers/Services/DAOs. To make things work "right", I have the Controller and Model classes in the MVC solution, and Services, DAO, and Security in the ClassLibrary solution. Unfortunately, this is causing all sorts of minor issues (example: extending the UserAccount object from the Entity Framework on the ClassLibrary side is ambiguous when I try to extend it on the MVC side for form validation).
The only solution I can come up with is to put EVERYTHING into the MVC project, and organizen what is currently in the ClassLibrary under the App_Code folder. It would solve some issues, but just seems "wrong" to me; my Java projects separated code into a src directory and views (jsp's) into ta webapp directory.
What do some of the more experienced .NET developers think?
Generally in .NET solutions, the best bet is to separate code into different projects only if that code may be useful to other applications, or when the code itself represents a complete solution to some problem domain. A class library that is only referenced by one application project is a waste.
Also, keep in mind that .NET does not allow circular references between objects in two different assemblies (which translates one-to-one with projects usually).
In your example I would suggest that you consider one class library for the model, services, and security... depending on what you mean when you say "services" though.
In most cases, data access is somewhat coupled to the concept of the MVC model, so you might consider putting the data access in there too... but if you have a very cleanly separated data access layer it might fit into it's own class library.
The controllers and views generally should go into the web project directly.
In general, my advice is to split stuff into separate projects ONLY when you have an actual "need" to do so. But assemblies and projects are NOT a good way to represent layers or tiers in most applications. Those are logical concepts that don't always map well to a physical project structure.
If you design your actual classes well and avoid tight coupling, you can usually move code into class libraries later if a real compelling need does arise.
What do you mean by making things work "right"? I find that most issues can be fixed by simply including the namespace in the web.config's namespace import section. When you do that, your models from the other assembly are automatically resolved and they show up in the MVC dialogs, and in intellisense when coding views.
I'm surprised I can't find more discussions out there about an issue that is really bothering me on our project using ASP.NET MVC.
How can you deal with a Visual Studio solution that has multiple projects? The MVC framework has the Models/Views/Controllers folder in the main project. But what if you want to break up your solution into multiple projects along logical groupings and bring the models/views/controllers along with it? When I think ahead to the end of the project, there will be many classes in each of these folders. It doesn’t paint a cleanly organized structure that will aid maintenance. We’d like a way to either move the classes to the projects that they relate to or at least use a folder structure to aid in the organization.
I assume that one option would be to use the same namespace in all of the other projects as is used by the main project, but I’m not a huge fan of that approach b/c this is not the approach that we’ve normally taken when defining our namespace.
I suppose we could at least create sub folders inside of the M/V/C folders and not carry forward the folder names to the namespaces. I’m assuming then that the classes could be found?
Some background on our project: It is a public facing web site that has many business transactions that the user can perform (about 50-60). Each transaction has a series of web pages that the user navigates through, in order to accomplish the different services provided by the site. We are using a single controller for each transaction (there have been long discussions on whether we should have a controller defined for each transaction or if we should use a higher level grouping and therefore reduce the number of controllers, but some information that we've encountered on the web (http://codebetter.com/blogs/ian_cooper/archive/2008/12/03/the-fat-controller.aspx) brought us to this decision.)
What are some recommendations? Have others solved this issue in a way that they are happy with?
Thanks
Jon.
Have a look at Areas.
Areas is a concept borrowed from MonoRail, which organizes controllers into logical folders.
http://haacked.com/archive/2008/11/04/areas-in-aspnetmvc.aspx
Areas are supported in Asp.Net MVC2.
Scott Gu has a blog talking about the Area Support here.
From his post.
Each area can be implemented as a
separate ASP.NET MVC project which can
then be referenced by the main
application. This helps manage the
complexity when building a large
application and facilitates multiple
teams working together on a single
application together
I always delete the "models" folder and reference separate class libraries that represent my business logic layers and data access layers. I also have some solutions where my controllers are kept in separate projects from my views. I agree that in larger applications, the single project model is inappropriate. Even in smaller apps, especially where model code must be shared with other applications, putting model classes in the actual MVC project is a bad idea.
We're building about 10 ASP.NET MVC sites which have a common set of features (and corresponding URLs, Routes, Controllers, Actions, and Views). The sites will also all share a base set of domain objects (e.g. users, companies) and base attributes on those objects (e.g. name, address, etc.).
But each site will also be highly customized and extended from the base. For example, our site for large, public companies will have "Subsidiary" and "Stock Symbol" fields on the Company domain object, while our site for startups will have a "Venture Firm" and and "Funding" attributes. Look and feel will also vary considerably, although we're trying to keep HTML as consistent as possible (modulo extra form fields for extra domain object attributes, etc.). We'll also be overriding images sparingly, so we can, for example, re-use the same button graphics across sites.
Anyway, we're trying to figure out how best to factor and architect things so that we can reuse as much code and as many tests as possible without limiting our freedom to add per-app attributes and vary the UI between apps.
I'm familiar with how to handle limited-customization multi-tenancy like you find in StackOverflow/SuperUser/ServerFault (or MSDN/TechNet for that matter), where the UI is a little different and the data model is more-or-less identical. But when the models and UI are very different (but inherit from a common base), I'm less sure how to proceed.
I'm less worried about operational issues, since we'll probably be running each site in a separate appdomain and hosting them on separate databases. I'm more worried about reducing long-term code maintenance costs, increasing agility (e.g. easy to add new features to the base without breaking derived apps), and realizing short-term dev-/test-cost savings as we build our 2nd, 3rd, 4th, etc. site.
I'm looking both for high-level guidance and suggestions, but also concrete suggestions for how to make that guidance real using modern ASP.NET MVC practices.
I realize this is a very general question, but for starters I'm looking for both high-level guidance as well as concrete tips-n-tricks for how to apply that guidance with ASP.NET MVC, including things like:
recommendations where to split base/derived across Visual Studio projects
source control tips to avoid forking
database schema tips (FWIW, our databases are all small-- under 10K rows per table, so dev/test cost is more of an issue than DB perf)
tips about re-using Controllers/Views/etc. corresponding to the "base" model attributes, especially re-using UI for things like "new customer" forms which will have a mix of base and derived attributes.
Anyone have good advice for how to architect a multi-tenant app like this?
Here's what we do, and it works pretty well for about 8 sites currently.
Define a core MVC project for your Controllers, ViewModels, HttpApplication, routes, etc. This will compile into a DLL and compromise the bulk of your site.
Create a basic set of default views, scripts, images, etc. for your site. These will server as defaults for your individual sites.
Per client, create any custom controllers, routes, etc that you'll need in a project that compiles to another dll.
Also per client, recreate any views, scripts, images that you'll want to use.
To make the above steps work together you'll need to write a little glue. The first piece of glue is a custom view engine. You'll want to customize the standard view engine to first look for views in your client-specific folder, and then the default folder. This lets you easily override the default layout per client.
The second method of getting everything working is to have your core application load the routes, controllers, etc from your client specific assembly. To do this I use the Managed Extensibility Framework (MEF) to expose a single Register method. Calling this method on my client assembly code registers the routes and any other client-specific needs.
Here's a general view of what my site folder structure looks like, with SiteContent being checked for views first:
- AppContent
- AppContent/Static
- AppContent/Static/Images
- AppContent/Static/Scripts
- AppContent/Static/Styles
- AppContent/Views
- AppContent/Views/Shared
- SiteContent
- SiteContent/Static
- SiteContent/Static/Images
- SiteContent/Static/Scripts
- SiteContent/Static/Styles
- SiteContent/Views
- SiteContent/Views/Shared
- web.config
- Global.asax
I have helpers that I can use like SiteImage and AppImage for use in my views. Also, I make each of my client sites use certain specific names for their master pages, that I don't ever define in my AppContent defaults.
I realize this is a rough overview, but it is working well enough for us right now.
I'm involved in a similar type of "suite" of projects currently which is focused on allowing customers to apply for products online but have very similar requirements for what information to collect, where the only differences are around product specific pieces of information or slightly different legislative requirements.
One thing that we have tried to do is create pages (model, view and controller combinations) that are reusable in themselves, so any application can use the page to capture information but redirect to the next page which may be different depending on what type of product is being applied for. To achieve this we are using abstract base controllers in the form of the template method pattern that contain basically all the required controller logic (including action methods with their applied action filters) but then use abstract methods to do the specific stuff such as redirecting to the next page in the process. This means that the concrete implementation of the controller used by specific application page flows may contain only one method which returns a RedirectToActionResult corresponding to the next page in the flow.
There is also quite a bit of other stuff that handles going backwards and those kinds of navigational things, but with the help of action filters you can get it set up that you don't have to worry about it once you get it up and working.
There are also base model objects which contains common functionality, be it validation logic or state persistence logic.
The data captured during the application process is persisted in database as xml serialized model objects which can then be pulled out and de-serialised once the application is completed and spat out in whatever format to whatever system the backend operations staff use to process applications.
The implications of this is that we have a project structure that consists of a base dll that contains top level abstract classes, interfaces and utility classes as well as html helpers, action filters etc. Then we have mvc projects which contain the concrete implementations of the base controllers, models etc as well as the views and masterpages.
The hardest thing is sharing views and I don't think we have properly got this sorted yet. Although with MVC 2.0 containing Areas I think this will become less of an issue but I haven't had a good play with it yet. (see Scott Gu's post on 2.0: http://weblogs.asp.net/scottgu/archive/2009/07/31/asp-net-mvc-v2-preview-1-released.aspx)
One thing I have POCed that looks like it will work is using a base MVC project to contain common views and then extending the default view engine to search that project on the web server when looking for a view to render (which is quite easy to do). Areas though is a far nicer solution.
As for source control, we are using svn and I think you are reasonable in being concerned about branches. It is not something that we have had to deal with yet, but we are probably going to go with git as it seems to make the process of branching and merging much less painful.
Not sure whether this helps you much but I would definitely recommend keep in mind abstract controllers and models, and also look at how you can use html helpers and and partial views to group similar pieces of functionality.
Mike Hadlow goes into good detail on how to accomplish this:
http://mikehadlow.blogspot.com/2008/11/multi-tenancy-part-1-strategy.html
One way to do this is to use branching in a source control system.
The main branch is for the common functionality. You then have a branch for customization and can merge changes out to the customization or back to the main branch.