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.
Related
First of all, sorry for any english mistakes. Its my first post on Stack Overflow and english is not my native language.
Im facing a problem on a web project being currently developed here at my company. We are making a large overhaul at a legacy application.
The application is being built by different teams in a manner that one team is writing a framework/foundation application that will be consumed by all the other applications (think as modules or even standalone satellite applications). All the applications are currently being written in ASP.NET MVC 3. and the framework (and the others) have views, models, controllers and static resources as any mvc applications (like the login screen, the menus, layouts, etc).
Currently we are organizing the projects like desired using a modified version of the MVCContrib Portable Areas.
My.Framework.Web
My.Sales.Web
My.Customer.Web
The MVCContrib project seems kinda of dead right now and we are looking for other approaches to solve this particular situation.
So my question is: We are doing this the right way? i mean, there is another way to treat a situation where strong interface reuse between projects are a necessity? This seems to me like a common situation but could not find anything similar (on scale) on the internet or books.
Best regards.
You can go with something like these:
The MVCContrib way (as you mentioned)
Griffin's MVC Plugin system
Simple MVC Areas solution
I think they are all have a disadvantage that is you need to copy View and Content files if you don't want them to be in your plugin assembly. But if you want to, you can use razorgenerator that can embed views in your assembly. So you can create areas then embed all of stuff in area assembly using razorgenerator and them reference it in your host project and register that area.
BTW, I think your application architecture (that is like Composite Web Application) is good for creating several products that have similar services or modules in them.
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.
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'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.
I have been working with ASP.NET MVC for a couple of months now and I'm still not happy with the layout of my project's solution. I am trying to construct a mid-sized website CMS that is as portable and reusable as possible and there are some obvious problems in the design of it. I am looking for some advice regarding how I should structure my solution in consideration of separation of concerns. I've found a similar question here, but it doesn't really target some of the issues I am facing.
Right now this is how my solution is laid out:
+Project.Controllers - All Controller classes
P+roject.Controllers.Tests
+Project.Core - Utility classes including repetitive tasks and some configuration handlers (this project needs to be better fleshed out)
+Project.Core.Tests
+Project.Models - Model classes, Entity Framework context, and Repository classes
+Project.Models.Tests
+Project.Web - All Views and Content
One major thing I am currently missing is a place to stick my business logic and I feel I've been wrongly placing business logic in my repository classes as well as intermingling it in controller actions. Obviously, I'm very aware of this problem, I'm just not sure where I should placing my business logic in that solution layout. Does my solution structure need to change or can I safely keep that business logic in my Models project? Also, I really don't like that my EF Context is in the Models class, but I don't know of a way to isolate the data layer code from the Entity Classes needed in my model.
How is everyone else laying out their production ASP.NET MVC solutions?
You might want to check out the layout the S#arp architecture project uses or the onion architecture as used in the Code Camp Server MVC reference application. Both projects have had allot of effort put into them by different people to get a good sepperation of concerns in the context of asp.net MVC and domain driven design.
Personally I'm only learning MVC. My experience comes from ASP.NET WebForms but I would go with the layout proposed in the link you gave. The second answer, that is:
Models
Views
Controller
Services
Tests - one for each project.
I would take EF Context and Repositories out of Models and into a data access layer, Project.Data and put your business objects in Project.BusinessLogic (?).
This gives the benefit of putting the two assemblies (Project.Data and Project.BusinessLogic) in other apps you might build on the same domain. That means your next project has a very useful starting point.
Hope that helps,
Dan