I have developed a MVC web application with ASP.NET MVC and im just wondering which Pattern you prefer to use with a MVC project?
The one that suites the problem. Now, what's the problem?
This is a fairly vague question! I have written quite a few articles over on DotNetSlackers that specifcally walk you through from a simple ASP.NET MVC application where the web page connects directly to the data source (think standard MS tutorial) all the way through to a full distributed nTier style application where the presentation connects via WCF to business layer (allowing business components to exist on seperate servers) which then connects to a data source through a pluggable data access layer (this last couple of articles I am still writing).
Get started reading these here: http://dotnetslackers.com/projects/StackOverflowInspiredKnowledgeExchange/ in the Three Tiers to MVC section.
http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange--Three-Tiers-to-MVC-Hooray-A-simple-MVC-application.aspx
http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Three-Tiers-to-MVC-Hooray-Logical-Separation.aspx
http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Three-Tiers-to-MVC-Hooray-Physical-Separation.aspx
Reversing dependencies article will be published in the next couple of days and the remaining articles will be out next week (roughly).
None, It's not a good idea to use a pattern for the sake of using a pattern. Design patterns solve a specific problem, and if you don't have that problem, don't use the pattern.
Related
i have been lately read some articles about BreezeJS. But till now i can't get my head around it.
What exactly BreezeJS is used for in details with examples not just words?
Can i use it in asp.net WebForms(most of tutorials target MVC projects), and if so how can i use it ?
Is there any concerns i need to take in consideration before i use it ?
I'm going to break your first question into two pieces:
Do you want to build a JavaScript / Single Page Application?
If you want a cross-platform application with a more fluid user experience, or have a need for offline operation, then Single Page Applications may be a good fit for you.
Why should I use Breeze in a Single Page Application? Can you cite examples?
John Papa has a great post about this that includes a few examples:
http://www.johnpapa.net/spajs04
You can use WebForms, MVC, or any number of other technologies to build a Single Page Application. For ASP.NET, people typically use MVC4 though. Here is StackOverflow post on that topic that might help:
webforms vs asp.net mvc for single page application - which to choose?
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.
I always used asp.net webforms with the MVP pattern, it works great for what I need, I basically create a project where all my business rules reside, validation etc... and I then implement my views in the webforms project.
Now we're starting to use asp.net MVC and using the MVP patter doesn't make much sense, right? So what could be a good approach to create a scalable and testable project using MVC that won't make me create my data objects and do validation on the controllers. I don' want to have the same code in different places...
If a web user wants to update his/her profile on the site, there would be some validation rules for when a submit button is pushed, like email address cannot be empty, must be valid and must not exist in the database.
These same rules should be applied if I try to update his profile using the internal admin section without having to duplicate the code there...
If you can point me to a good sample project that deals with this would be great!
Thanks in advance!
You should use the MVC pattern with ASP.Net MVC.
The NerdDinner tutorial is a pretty detailed example for MVC, you can also get a book that includes the tutorial (you might want to wait for the version that covers ASP.Net MVC 3). There are plenty of resources on Microsoft's ASP.Net site.
You can always consult Google.
ASP .NET MVC was built with the Model-View-Controller (MVC) pattern in mind. That would be the pattern you'd want to use.
In addition to the resources magnifico provided, I know others have recommended the some other tutorials. I don't know if these have been updated to the latest version of the framework, but they should still serve as decent beginners.
MVC Storefront series
MVC Music Store
Also the Microsoft Patterns & Practices group recently released Project Silk which gets into more advanced techniques involving a lot of AJAX management of the UI. There's interesting stuff there.
I'm struggling to find a good reference application for ASP.NET MVC. By "reference", I specifically mean an application that flexes all of the framework's features in the Microsoft-sanctioned manner, such as:
Master pages
Partial views
Strongly-typed models
Authentication
Custom routes
etc...
The open source examples that are out there (CodeCampServer, SutekiShop) either add significantly to the base framework or don't use all of the baked-in features.
Have you seen Rob Connery's MVC Storefront Webcast Series?
http://www.asp.net/learn/mvc-videos/#MVCStorefrontStarterKit
Source Code:
http://www.codeplex.com/mvcsamples/
I asked more or less the same question here: What are some projects which are examples of best practices for ASP.NET MVC?
As for official, the closest would be Rob Connery's which was mentioned.
This isn't official but you could check out Kigg:
http://www.codeplex.com/Kigg
It's a sizable Asp.net MVC Digg-clone with some decent code in it. Used on dotnetshoutout.com
I would consider the Nerd Dinner MVC reference app: http://nerddinner.codeplex.com/ for people just starting
While this might be a little late to the show, I believe that the ASP.net team would like people to start using the MVC Music Store as the official mvc reference example. The Music Store application is using the Razor view engine with Entity Framework's code first approach (also demonstrates database first) along with examples of dependency injection, test driven development, jQuery integration and getting and using NuGet packages.
A second reference example seems to be more on the cutting edge of things and is provided by the Patterns and Practices people. This is called the Silk Project and takes advantage of the latest web standards like HTML5, CSS3 and ECMAScript 5 along with modern web technologies such as jQuery, Internet Explorer 9, and ASP.NET MVC3.
These together would probably show you the newest in ASP.net MVC development along with some pretty neat ideas and examples.
I've been reading a few things about ASP.NET MVC, SOLID and so on, and I am trying to figure out a simple "recipe" for small-to-medium ASP.NET MVC apps that would put these concepts together; the issue that I am most concerned with is ending up with controllers that are too complex and being like code-behind files in webforms, with all type of business logic into them.
I am considering the following architecture, for a small data-driven app:
Controllers: only handle requests, call an appropriate service and return the action result to the View;
Models: POCO, handle all the business logic, authorization etc. Depends on repositories, totally ignorant of persistence infrastructure.
Repositories: implement IRepository<T>, use dependency injection and is where my db code will reside; only receives and returns POCO.
I am considering having services between the controllers and the models, but if they will just pass forward method calls I am not sure how useful it would be.
Finally there should have unit tests covering the model code, and unit+integration tests covering the repository code (following the "red-green" practice, if possible)
Thoughts?
Ian Cooper had a good post on exactly this recently:
The Fat Controller
Simple recipe: (view)Presentation Layer using ASP.NET, (controller)Code Behinds or AJAX Services Layer, (model)Application Services layer, Business Model layer, and Persistance/Data Access layer.
Of course you can slice and dice numerous ways to deal with complexities in order to build a clearly readable and understandable application.
For a recent discourse on the subject, which I have found to be very good, check out this newly published book: Microsoft .NET: Architecting Applications for the Enterprise.
These walkthroughs are quite helpful:
MVC Framework and Application Structure
Walkthrough: Creating a Basic MVC Project with Unit Tests in Visual Studio
Also see: aspnet-mvc-structuring-controllers
Rob Conery has the best answer IMO.
Check out his MVC Storefront Application, which comes with complete source code and video tutorials.