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.
Related
I am wondering what is the better way to go. I created a webapi project and am currently working on making my api.
In the future I want a full asp.net mvc 4 website and that could also contain forms to insert data into my database.
I am not sure if I should
a)
Make a new area in my web api project and build my website from there.
b)
Keep it in the same area and just make some new controllers and such in the web api project.
c) add a new asp.net mvc 4 project to my web api solution project.
Definitely two projects. In fact, I'd actually recommend three projects:
MVC website
Class library, for sharing your DAL/Service layers
Web API
Your MVC site shouldn't need to query your Web API, that's just going to create HTTP latency that's unnecessary. Both your MVC site and your Web API, are just "frontends" for your class library. They will both reference the class library and interact with the class library.
A Web API is only necessary if you're trying to provide third-party access or you're interfacing with a project in another language. If everything is .NET then just share the DLLs and call it a day.
K. Scott Allen recently wrote a brilliant post on the Coexistence of ASP.NET MVC and WebAPI it covers the most common scenarios and when it's appropriate to use WebAPI with MVC or when you should just use MVC.
I would use that as your guide pick the solution that best meets your current needs. My advice is to keep it simple and if your requirements are simple then there is no reason not keep WebAPI and MVC in the same project - it works just fine. As your requirements change you can always split them up into different projects or solutions, but by then you will know exactly why you are doing so.
http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx
absolutely,
go through link http://efmvc.codeplex.com/
which is the best architecture to develop the big apps
may this one is help you...
another BEST one MVC N-Tier architecture
MVC ---------> WEB API (services)------ > here BL | DL(ORM) | DB)
which you create this in same solution and build the app...
Separate projects for the web api and the web interface will help split things up, but it does cause duplications. We went that way recently and it works well, but it caused a few problems.
Arguments for having a single project :
Since we don't have a domain name yet, we have our API on the 8080 port. We could use a directory binding to make the API accessible from a sub-directory of the web interface but we were worried about production only bugs about absolute path resolution.
Many settings are shared between the two projects so we have to copy them in both web.config files.
Arguments for having multiple projects :
They are easier to upgrade since they can have different dependencies and they can be built totally independently. For example, our API project uses a few more recent versions of some dependencies.
It forces you to extract all of your business logic into a separate library and makes it easier to think about both projects as separate sub-systems.
It is easier to setup the web interface to a separate machine if the load is too much. This is a concern for us, but that may not be your case.
If I had to make this decision again, I probably wouldn't bother with separate projects unless the system was extremely complex and I needed the additional structure. An argument can be made for both options, but I think the deployment headache it brings is not worth it.
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.
This is a ASP.NET MVC beginner question (I'm in phase of developing NerdDinner)... I have assignment to create ASP.NET MVC cms (with its own design) and portal (also with its own design) that will display data that's being handled by CMS. I was wondering if I will have to make two individual projects in Visual Studio or I will have to use one project and place portal section in specific folder.
I know that my question is a bit premature (according to fact that I still haven't finished tutorial) but I'm bit impatient :)
On server (commercial hosting) I would use only one hosting account... this thing with URL routing is a bit confusing to me, CMS is practically also optimized for SEO.
I would like to the structure of URL to be:
---- PORTAL ----
www.domain.com
www.domain.com/Menu1/Submenu1
www.domain.com/Menu2/Submenu1/SubSubmenu1...
etc.
---- CMS ----
www.domain.com/CMS
www.domain.com/CMS/Whatever
Thanks,
Ile
It all depends on the functionality of the portal and the MVC cms.
For starters I would have a separate solution for the Model/Data Access that way you can have as many MVC projects without duplicating your data access.
From your desired url structure I would probably have the CMS as a separate controller and sub folder. Alternatively if your using MVC 2 you could look at the areas support which will probably give you a little more flexibility.
If you want the solution to be a bit more complex/flexible you have a number of options:
If both the portal and MVC cms are going to have he same functionality and page layout you have two master pages and determine which mater page to show when returning the view. You would specify this in the routing so multiple routes would point to different controllers.
If the layout/functionality differs slightly but one controller can still manage both you could have a separate controller project and two mvc projects which only contains the views, javascript and images so both mvc solutions look at your controller solution. With this option you would probable end up setting up two websites on your domain one under the root and the other under the CMS folder (in your MVC app you will prob need to block routes to /CMS so it will be processed by your CMS app).
Finally if both differ hugely have two separate projects but keep your common data access project, as above you may need to set up two sites on your hosting package.
Suppose I have a very large site like amazon.com. I’d like to use asp.net mvc for the whole site but having one large project with hundreds of contributors is not practical. I’d like to split the work into projects like books, tools, toys, groceries, etc. for each department. Then when they build and deliver a new release I can just drop the “books.dll” into the site and it all magically works. I see this thing called “areas” but it looks like they’re still part of the same project. I need something that could potentially be stored not just in a separate project but a separate TFS instance as well. The departments would only ever come together on my test/production servers and hopefully just by dropping in DLLs. Anyone know of a way to do this?
Asp MVC 2 has support for Project Areas catering for this development scenario
More detail at Phil Haack blog
Have a look at areas in ASP.NET MVC 2.0.
Shoulda looked harder before posting:
http://msdn.microsoft.com/en-us/library/ee307987%28VS.100%29.aspx
"Walkthrough: Creating an ASP.NET MVC Areas Application Using Multiple Projects"
(self-slap!)
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.