Are there any tutorials/examples on how to create an asp.net mvc app without the model being managed by a database (through linq2sql or entity framework).
I've to create a frontend for a server which has a json based api. I would like to use mvc 3 or 2 and have most of the features of mvc still in place (like data annotation and validation).
Any tutorials or examples on how to do this? I tried to search them but all examples i find are based on entity framework or linq.
I agree that most of the examples/tutorials out there are using entity framework. This being said the process would be similar:
Create your model classes.
Create a repository working with those model classes. This repository should implement an interface which contains all the operations you need with those models like GetUser, SaveUser, etc... In the implementation you connect to the remote JSON API server to fetch data.
You create a controller which takes the repository interface in the constructor. Setup a custom controller factory so that a DI framework could provide instances of your controllers.
Define views and view model classes.
Controller actions talk to the repository via the provided interface to fetch models, maps those models to view models and returns them to the corresponding view to be shown.
Useful tools:
MvcContrib (many useful helpers)
AutoMapper (for mapping between models and view models)
FluentValidation.NET (for validating models)
MVC 3 has extra support for JSON which you might want to look into.
Or use the futures with MVC 2.
Related
I'm Developing ASP.NET MVC Web Application project, and I'm using Entity Framework Database First Approach, So I would like to make validations on generated model classes, I know if i make validations on them directly, then my model validations will be overwritten every time my domain models are regenerated.
So I made a research, and found two approaches to use for this scenario:
1- Using buddy classes (How to add validation to my POCO(template) classes).
2- Using ViewModels and Auto-mapping them to my Entities (Designing an MVC repository using ViewModels
I see some sort of redundant code in these two methods, so, my question is:
Which one of the two approaches is best to flow?
1) This is the correct solution for adding validation metadata for the Entity Framework objects. The validation will be triggered automatically by EF before calling SaveChanges()
2) This is an aproach for creating Data Transfer Objects from your EF objects. You normally do this when you want to return the objects to the client (like in JSON format) - and you don't want to expose all the EF specific properties (like navigation properties, primary keys etc)
I'm new to ASP.NET MVC and inherited a project that uses the technology.
Such Web project contains three folders: Views, Controllers and Model. As I understand it, the Model contains in fact your domain / business logic and is called by your controllers. The controllers themselves act as delegators between Views and Model.
Now, in a typical layered architecture, there should be no references in any project to the Web/UI project.
I find this quite confusing:
-> The UI contains the Model, which is - in an ideal world - based on "Domain Driven Design"-principles.
-> The layers on top of the UI (Services and DataAccess) cannot have a reference to the UI
How can you write efficient services and dataaccess layers if they do not know your model?
What am I missing here? Is the Web.Model different from "DDD" and should I still have a separate BL project? If that is the case, then what is the Web.Model supposed to contain?
I view the Model as a concept. You can have a completely separate project containing your Domain (your entities, your services etc.) and reference that in your "UI" project. In this scenario this will be your "Model".
This is what I typically do, In my Models folder I keep "ViewModels", which I use for Binding/Validation (for the UI).
For example, If I have an Employee but I don't necessary want to use all its properties (or for that matter different properties), I will create an EmployeeViewModel adjust it the way I want, I'll add validation (if required) and I'll pass it to my View.
This is by no means, "the right way"/"only way", but It worked for me in the past, and I thought I'll share (also, I'm pretty terrible in explanations, so I really hope this post makes sense, in case it doesn't or clarifications are needed - please let me know).
You necessarily do not need to have your model in the same project. You can ofcourse have those in different layers.
This is how i usually setup my projects
1) UI Project - This is an MVC Web application type project where i will have my controllers and it's views and other UI related stuff
2) Business Entities - This will be a class library type project where i will define my domain objects ( Ex : Customer). This mostly looks similar to how my DB schema looks like. These are usually just POCO's which represent my domain modal ( I use this for the CodeFirst Database generation).
3) Data Access - This will be another class library type project which has the data access classes. Usually my repository class/interfaces, my DBContext class and other data access classes will be in this project.
4) Tests - Unit tests for the project
Business Entities project has been added as a reference to the Data Access Project so that i can use those classes in my Data access code.
Business Entities and Data Access Projects are added as references in UI Project. I would call the data access methods from my Controllers/ Service classes.
You may also add a Service/Business logic layer between your controller's and Data access layer as needed.
I have few ViewModel classes also inside my UI project ViewModels folder. I use this for some screens where i have to show data from multiple domain objects. I have a mapping/service class which maps the domain object to view model object. If your project is bifg, you may keep this as a serperate project under the same solution
Views Contain your HTML Layouts
Controllers do the heavy lifting of getting data from the models or the models themselves and passing them to the Views.
Models are used to do actions for your BL or fetch data.
Tip : You can use a EntityFramework ( i'm recommending it because it's easy to get started with ) to fetch your data and it's dead simple to setup thus eliminating your DAL and saving you time from writing everything yourself.
Services : you can have controllers that return XML/JSON (other format?) by converting the data you have got from the DB to XML/JSON and returning that instead of a view.
Take a look at MVC 4 WebApi for more details,Note that you can pretty much the same thing with mvc 3 too
Also refer to asp.net/mvc site for tutorials to get you started, they are really useful.
I'm starting from a point very similar to: Domain Entities, DTO, and View Models.
The advised use of DTOs to map between the domain model and the MVC's ViewModel seems consistent expectations. I seek details of how to bridge the domain model (Entity Framework-based project) to the WebAPI mvc project.
I'm starting with a project of simple POCOs (generated by EF PowerTools to reverse engineer my existent db) that I want to connect to an MVC4 WebAPI project.
I expect I'll be adding business logic to the baseline POCO project as my solution evolves and perhaps this is the crux of this issue. The business logic that transforms the POCOs into something that can be mapped to the MVC project.
Exactly how do I wire these projects together so i can start creating controllers in the MVC project that knows about the entities of the EF project? Automapper? Can we point to posts/docs where this specific feature of Automapper is employed?
You don't want controllers that knows about the EF entities - that's the whole point of this. :)
You yourself say that the DTOs should be used to map your domain to your view model, and then you ask "how can I bridge my domain model with the mvc controllers?". You've already answered this - with DTOs!
The DTO serves as a transport layer between complex business objects and models used to display a certain view. Both of these have special requirements that don't strictly relate to "just data" - hence using DTOs will give you a greater decoupling and separation of concerns.
If you don't decouple domain from view model, you will be forced to directly reference your EF objects in your view model code, which exposes unnecessary data and functions "up the chain".
Now, if you use WebAPI as a way to ship data then I think you could usually get away with sending the DTOs, since WebAPI data usually wouldn't be implementing view model logic. But YMMV of course, depending on how you plan to use your controllers.
For AutoMapper I'd say it's best to start with their own docs (they even use DTO examples in them): http://github.com/AutoMapper/AutoMapper/wiki/Getting-started
I'm new to MVC and even though there is a lot (and I do mean a lot) of information out there that is very useful - it's proofing very difficult to get a clear understanding on how to achieve my exact requirements with MVC 2.0.
I would like to set up a solution as follows:
Provide a web UI using an MVC 2.0 project.
Use Linq to SQL classes project for data persistence.
I have a two separate code modules that will need to access the above Linq to SQL model - so I won't be able to include my Linq to SQL model directly in the MVC project itself.
Also I have a Business Logic layer in front of my Linq to SQL project.
My questions are:
How do I set up the Model part of my MVC application to point to my Linq to SQL project via my BLL?
How do I perform web app validation? Can I use MVC 2.0 Model Validation? If not what are the alternatives?
Finally (and slightly aside) - What is the ViewModel and how does this differ from the Model?
So many questions. But this is an exciting new technology and data access issues aside, everything else I've got to grips with very quickly and I think MVC 2.0 is fantastic.
Thanks for any pointers you can provide.
How do I set up the Model part of my
MVC application to point to my Linq to
SQL project via my BLL?
Typically you'd use a repository pattern for this. Your controller has a reference to your repository - the repository returns your domain objects from your database. The MVC app has no knowledge LINQ to SQL exists.
How do I perform web app validation?
Can I use MVC 2.0 Model Validation? If
not what are the alternatives?
Put view models in your MVC project. These view models may closely align with your domain models but their concern is to be the presentation model. Put your data annotations for validation on these view models - the MVC framework will automatically ensure validation occurs on these view models decorated with data annotations. It's pluggable so you could use alternatives - but with MVC 2, it's baked in fairly well and this includes client side validation.
Finally (and slightly aside) - What is
the ViewModel and how does this differ
from the Model?
I partially answered this one above. the shape of your domain models may not be the shape you need to display your views - view models are great to bridge this gap. Additionally, even if the shape does match exactly - view models are still a good idea so that you can put UI validation code there and other presentation meta-data on them (since you do not want anything related to presentation logic on your domain model).
Here's link for view model patterns.
Hope this helps.
You can add a reference to the objects exposed from your BLL assembly and use them as your Models.
When you want to add validation to classes that are generated use buddy classes.
A ViewModel is a custom-shaped aggregate of Model data. There is exactly one per View, as the ViewModel's purpose is to surface exactly the data needed by a particular View in a convenient and concise way.
An example might be a View that contains both Order and OrderDetail information. A ViewModel can hold internal references to the repositories and business objects for each type. Properties of the ViewModel merge together the data from these objects.
ViewModels will be useful in your case also because you want your Models to be in a separate assembly. You can apply the DataAnnotations to ViewModel properties for validation. You would make the "raw" business object models internal properties of your ViewModels, and expose public methods to retrieve and persist data.
In my first ASP.NET MVC applications, the model was a simple O/R mapping between a table and the classes, managed by the Entity Framework.
Now I would like to add some meat to this skeleton, and introduce business methods for the generated classes. What is the recommended approch to this in ASP.NET MVC (with Entity Framework)? My favorite would be solution which also can be used in a service layer, with no ASP.NET MVC references, so that the same domain logic also could be reused in a desktop client.
Technically, I think it should be possible to extend the generated classes in a way which preserves the additional business logic even if the O/R classes need to be refreshed. (This is more a question related to the Entity Framework however.)
Edit: Many thanks for the contributions, and the information about the next version of Entity Framework (4.0). Building two sets of classes, one auto-generated to represent the data in the persistency layer and one for the actual business logic sounds interesting.
Within MVC.Net, the model is the least clearly defined part. In my opinion, it's basically the rest of your application (i.e. anything not related to the View or the Controller). The O/R Mapping part of your application should probably be outside of the "Model" also, as this is more of a data layer. The Model, should really deal in business objects and create views of your data to pass to the View.
There are lots of differing opinions on this, but I think it's best not to think of MVC.Net as traditional MVC Architecture.
If you are using EF v1.0 right now, the Entity Framework is very intrusive into your application, which means that you cannot create POCO very easily. The way you can extend your model is by using the partial class. So when you refresh your model, the partial class you did will still be valid. The Entity Framework team realizes this is a problem , and have improved this in next version (EF V4.0).
NHibernate is much more friendly and allow you easily extend your business logic.
I really think this blog post by Jeremy D. Miller is very good at pointing out the problem.
Abstract your Business Layer out into another project, then pass an instance of it onto your mvc controller using something like structure map. You can then call this Business Layer from your controller to retrieve your business entities (Model) and pass them on to the UI. This will allow you to resuse your Business Layer in your desktop application.
Not only meat but also some clothes and a style could be added to this project to make it seem chic. It depends on the time you have for the project. If you have time, I could suggest you to get a look to TDD and the frameworks that could be used with TDD such as Castle, NUnit, Moq etc.
As you mentioned a service layer is a must for any project but with these kinds of frameworks you could design your architecture more robust.