IS there a service or third party product can help show me the code flow (start to end, including all function and class types) related to MVC 3&4 ?
I have a complex project and need to understand the underlaying framework process flow and functionality around that - any pointers appreciated!
this will depend greatly on your project as the flow in such a beast can vary dramatically. However, if we are talking about the framework itself, then that of course is well defined and follows the pattern below:
Receive first request for the application
Perform routing
Create MVC request handler
Create controller
Execute controller
Invoke action
Execute result
there are many examples of complex projects on codeplex (mvcstore for example), that will help you explore the implementation of the above.
Also, take a wander thro:
http://downloads.academy.telerik.com/svn/school-academy/Meeting-24-ASP.NET-MVC/ASP.NET%20MVC%20Pipeline.pdf
http://www.codeproject.com/Articles/43153/Beginners-Guide-s-to-ASP-NET-MVC-Framework-Part-1
I'll be honest, this stuff can be daunting at first but once you understand the pipeline, the project nuances all fit in far easier.
good luck
Related
I'm creating new project (just to learn). It will be written in ASP.Net 5 MVC 6 and EF 7 code first approach. Also I want to make service layer i.e. all business logic written in F# 4.0 (never wrote a line in that language except for some tutorials). This means I'm creating this project in everything new or use tools that I not used before.
Currently I have empty solution. So first task I've set before me is to create authentication logic. All tutorials show how simple it is however: I do not want to have any logic (other than view manipulation) in controllers. So I need to create a service that will be called and login/register user.
The problem is that all business logic will be written in F#. I wasn't able to find any materials on how to achieve such task. Can you guys guide me how to use Microsoft identity with code first approach in F#.
Any guide lines, tutorials (yes I've looked through uncle google) would be appreciated.
This may sound like a dumb question on the surface, but why does the Hot Towel SPA Template include Breeze at all?
I've been spending the last few days learning Hot Towel and its dependencies, and as far as I can tell, nothing in the template actually uses Breeze. Perhaps that is going to change with some future release?
Sure, Breeze is a good library. But it's bound to CRUD methodology and requires you design your ApiControllers a particular way. (Metadata, SaveChanges, etc.) see here
It also guides you to Entity Framework. While this is more of a soft-dependency, since Breeze also shows a sample without it, it still guides you down a similar pattern of implementation using a modified repository pattern.
If you are using a NoSQL datastore, or CQRS patterns instead of CRUD, then Breeze becomes very difficult to use. There are alternative libraries for data access that work well in this style, such as AmplifyJS.
But the rest of Hot Towel is excellent! I especially like Durandal. So the question begs, if the template isn't actually doing any data access - why include any data access component at all? It would be better to ship it without Breeze, and if the end-user wants to use Breeze, or Amplify, or whatever - then so be it. The rest of Hot Towel would continue to shine as a great SPA implementation.
Matt - Good question. Since I created it I guess I should answer :)
When I built the template I had a focus on providing enough to get folks going with the right tools, and just enough starter code to guide the way. I did not want anyone ripping out code. I'm not a fan of templates that start you down a path and make you remove tons of files and code and change direction. Those are samples.
Samples are good. In fact, samples can be excellent (like the other templates, which I feel are more like samples). Those serve another purpose: to show how you can do things.
Back to the Hot Towel template ...if I include code that uses Breeze, I would be tempted to add a datacontext.js and a model.js on the client. They would contain data access code and code to extend the models on the client. Then I would be tempted to add a controller, some server side models, an ORM and a database. Once there, I'd want to use the data in multiple screens, which leads me to more Knockout and caching with Breeze. Then I might be tempted to add editing, which would lead to change tracking. Soon I have a full blown app. Or more conservatively, I have a sample again. While these approaches would provide more guidance on how to put these together, they would not help you "get started" with a template where you can just start building and adding your own code. If I stop short of some of these features, it's still walking down a road that requires you to change how I did it.
As it stands today, HotTowel is pretty darn close to a template in the truest sense. You create a new project and you are off and adding your own code.
You could argue (and you may be) that Breeze shouldn't be in there since I don't use it in the template. Nor do I use moment.js, BTW. However, I argue that they are both excellent libraries that I would not want to build a CRUD based SPA without them. Breeze is flexible, as you suggest, so you don't have to walk a specific path.
The best way to understand the value of Breeze is to build an app that has its features but without Breeze. Then you can see how much code that takes and how involved it is. For one such example, see my intermediate level SPA course at Pluralsight where I do exactly this: http://jpapa.me/spaps
So you ask "why Breeze?" ... because I strongly recommend it for building a SPA.
Thanks for asking and good luck !
Thanks for asking the question.
John, as author of HT, has offered an answer. I, as a principal of the Breeze project, am inclined to agree with him :)
HotTowel generates a foundation for you to build upon. It is not the building itself.
It is a foundation intended for a specific kind of application, a CRUD application based on a specific set of cooperating JavaScript and ASP.NET technologies. Breeze is a contributor ... but not the only one. Knockout, with its MVVM design and 2-way data binding, is particularly well-suited to the data-entry tasks typical of CRUD apps.
Of course there are other kinds of SPAs. There's an important class of apps that mostly present information and accept little user input. Such apps don't benefit as much from data binding and the people who write them can get pretty hostile about data binding in general and KO in particular.
My point is that HT targets a particular class of application ... one that happens to be immensely successful at least when measured by sustained popularity. It delivers the goods for people who build those apps. It may not be the right starting place for other kinds of apps.
It is true that the easy road to Breeze runs through Web API, EF, and a relational database. Take those away, and you may writing more code on the server (and a little more on the client). That may be the perfect trade-off for you.
The authors of Breeze would like to make that path easier. I don't think BreezeJS makes it harder. I don't understand your statement "Breeze becomes very difficult to use." Have you tried it?
Your client can communicate with any HTTP resource in any manner you chose. It is pretty easy to use existing Web API controllers (albeit easier with Breeze Web API controllers). You can use amplify.js if you prefer (btw, you can tell Breeze to make AJAX calls with amplify). You don't even have to use the Breeze EntityManager to query and save data if you don't want to.
The rest of BreezeJS may still have value for you. There remains plenty of work to do after you've figured out how you'll retrieve and store data and whether you prefer Entity-ChangeSet style or Command/Query style.
You'll have to find answers to these questions:
How will you shape the raw JSON data into bindable objects?
How will you hold on to these objects and share them across multiple screens without making redundant round-trips to the server?
How will you navigate from one object to a related object as you do when binding an Address to a combobox of StatesAndProvinces?
How will you track changes?
How will you validate them?
How will you store some or all of the data in local storage when the app "tombstones"?
Breeze can help with these chores even if you don't want it to query and save for you.
And if you're answer remains "I'll do all of that myself, thank you" ... well, removing Breeze from your HotTowel project is as easy as:
Uninstall-Package breeze.webapi
I have the following real world scenario, somewhat simplified for the sake of this example
I have an object, let's call it Movie which will consist of several attributes, such as
release date
actors (array)
genre
rating
I need to be able to have a form where a new movie can be entered, with the following elements on the form:
date calendar
drop down list with actors
grop down list with genres
rating field with stars
What would be a clear consice way to organise my code using asp.net mvc, please outline where
data access logic goes
business logic goes (validation etc)
I would like to use ViewModel concept here
So far I have
Movie model
MovieViewModel view model
IMovieRepository interface
But I am unclear how does the actors/genres arrays fit into this and where do I fetch the data for it....does it go into IMovieRepository interface? Do I create another interface for it, in other words do I create an interface for a ViewModel? Do I create an interface for fetching genres too?
Another question:
How do I use ViewModels? Do I need to change anything in the application settings?
Controller action has something like View() in their body....how do I pass ViewModel there? Do I need to?
All in all, I just want a simple example of how you would implement the scenario above.
I am new to MVC and trying to make sure my code is organized well.
I remember very good word from Mike Cohn about Agile,"Best Practice Is Not Exist"
So you should always keep improving and refactoring not only for your code but also for your design, architecture, methodology, etc. and to do this You will need the following:
Put the maintainability as a none function requirement at the begging of all your work
BDD (Behavior Driven Development)
TDD (Test Driven Design)
TDD (Test Driven Development)
Unit Test with appropriate code coverage percentage
Automate your build deploy and test (Full automation of all repeated activities)
I know it a bit long introduction, but it necessary to understand me why I will advise you doing my approach as the following
My default approach in MVC project as the following
Flatten ViewModel that mapped using mapping layer by using
mapping library
Domain Model Consider DDD instructions
Service Layer that working with controllers as services
business logic
Repositories that used by the service layer and unit of work
But as I told you, Best Practice is Not Exist so I will start my development using BDD and TDD, and to implement this I founder and create a framework "DevMagicFake" that published on CodePlex, this framework will enable me to finish and complete my view and make it real working without any design or code for the underline layers at all
After the feature is working with all unit tests that cover most of it's behaviors, I will start refactoring the whole
ViewModel
Mapping
Service
Repository
etc.
and for each refactor I run all needed unit tests to find-out if my refactor break my code or breaking the accepted and knowing behaviors of the application, if it happen I will fix any break
So for example to save a Customer and retrieve it I will use only one line of code in each action method like the following
public ActionResult List(CustomerVeiwModel customerVeiwModel)
{
var repository = new FakeRepository<CustomerVeiwModel >();
repository.Save(customerVeiwModel);
And to retrieve the customer I just need to code the following:
var repository = new FakeRepository<CustomerVeiwModel>();
var customer = repository.GetById(1);
So I always take the decisions of the ViewModel, Repository, Architecture, etc, after 2 points
Feature completed and worked as the customer or the business expert
expected
I have unit tests that cover all the feature behaviors and response
This will make me aware of what to do about design, develop architecture and make me confidence that my code really work with high quality and as the customer expected
At the end, There is just one word, I always keep refactor and refactor, every new feature, modification, problem or issue happen to me it may lead to new architecture concept or design decisions that will change the whole application and I am always ready for them.
by the way you can download MVC3 project that use my approach form DevMagicFake on CodePlex, you will find project called "TryFakeMVC3"
I recently started reading about ASP.net MVC and after getting excited about the concept, i started to migrate all my webform project to MVC but i am having a hard time keeping my controller skinny even after following all the good advices out there (or maybe i just don't get it ... ).
The website i deal with has Articles, Videos, Quotes ... and each of these entities have categories, comments, images that can be associated with it. I am using Linq to sql for database operations and for each of these Entities, i have a Repository, and for each repository, i create a service to be used in the controller.
so i have -
ArticleRepository
ArticleCategoryRepository
ArticleCommentRepository
and the corresponding service
ArticleService
ArticleCategoryService ...
you see the picture.
The problem i have is that i have one controller for article,category and comment because i thought that having ArticleController handle all of that might make sense, but now i have to pass all of the services needed to the Controller constructor. So i would like to know what it is that i am doing wrong. Are my services not designed properly? should i create Bigger service to encapsulate smaller services and use them in my controller? or should i have an articleCategory Controller and an articleComment Controller?
A page viewed by the user is made of all of that, thee article to be viewed,the comments associated with it, a listing of the categories to witch it applies ... how can i efficiently break down the controller to keep it "skinny" and solve my headache?
Thank you!
I hope my question is not too long to be read ...
This is the side effect of following the Single Responsibility Pattern. If each class is designed for only one purpose, then you're going to end up with a lot of classes. This is a good thing. Don't be afraid of it. It will make your life a lot easier in the long run when it comes to swapping out components as well as debugging which components of your system aren't working.
Personally, I prefer putting more of my domain logic in the actual domain entities (e.g. article.AddComment(comment) instead of articleCommentService.AddComment(article, comment)), but your approach is perfectly fine as well.
I think you are headed in the right direction. The question is how to instantiate your services? I'm no MVC.NET guru, but have done plenty of service oriented Java projects and exactly the pattern you are discussing.
In Java land we would usually use Spring to inject singleton beans.
1) You can do the same thing in .NET, using dependency injection frameworks.
2) You can instantiate services as needed in the method, if they are lightweight enough.
3) You can create static service members in each controller as long as you write them to be threadsafe, to reduce object churn. This is the approach I use in many cases.
4) You can even create a simple, global service factory that all controllers access, which could simply be a class of singletons.
Do some Googling on .NET dependency injection as well.
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.