I would ask also for best practices and patterns for asp.net MVC, using this example:
I have a project. This is its architecture:
Models
Controler
Views
Tools
In models folder I have every single ViewModel in separate class field. All of table declarations (objects) I put in one file (AccountModels.cs or ForumModels.cs). I have a separate file for EF context (MyAppContext.cs).
Controler - here I have only Controler classes. But maybe part of code will be better example and suggestion what can I improve:
private AppContext db = new AppContext ();
[HttpPost]
[Authorize]
public ActionResult AddGun(GunModel model)
{
if (ModelState.IsValid)
{
Gun gunToAdd = new Gun
{
Tilte = model.Tilte,
AuthorID = UserTools.getUser(User.Identity.Name).UserId,
AddDate = DateTime.UtcNow,
Content = model.Content,
CategoryID = model.CategoryID,
CategoryName = GunsTools.getCategoryName(model.CategoryID)
};
db.Guns.Add(gunToAdd);
db.SaveChanges();
return RedirectToAction("Details", new { ID = gunToAdd.ID });
}
return RedirectToAction("Index");
}
This is a part of controler with AddGun Action. Others ActionResults are similar - generaly I use lambda expression on my db context to get values etc.
Views - Views in separate folder, for Partial Views I set special prefix (for example - _NavigationPartial.cshtml or _CalculatorPartial.cshtml). Is there anything for improve here? Of course Views use ViewModels, not Models.
And at least - Tools. I've put here some classes and methods to prevent from repeating code. Here is some methods witch returns from database some objects or just strings, like GetUser(..) or GetCategoryName(..). Is it a good practise at all?
I think that many young MVC developers have the same project architecture (I personally saw it in a few companies) and many of them perhaps also wants to improve something in theirs projects to be a better programmers.
Regards
As noted in the comments above, it's hard to answer such a broad question, but I will make a couple of observations
It's not a great idea to use your database entities directly in your Controller, because that tightly couples your controller to the database and can lead to data being exposed to your view that really doesn't belong there.
Instead you should have a separate data layer that abstracts away the details of what a Gun entity is (from the perspective of the database) and what a Gun Model is (from the perspective of the View)
A randomly selected but good SO question about this is found here
You could consider using Dependency Injection (DI) for your controller
so that you have a constructor that looks like this:
readonly AppContext _db;
public GunController(AppContext db)
{
if (db==null) {throw new ArgumentNullException("db is null");}
_db=db;
}
You'll need to use a DI Container to this up. A randomly selected (but really good) article can be found here
Above all, keep asking questions, but try to keep them more specific i.e about specific areas of your app - and in no time you will have a really good picture of what is and isn't good practice!
Related
I've got an ASP.NET MVC application and am looking at ways to improve readability, testing, etc. Currently, much of the business logic is in the controller and I would like to move this to another location.
Here's one idea I have been looking at using: Entity framework creates entity classes for me (e.g. Product, Customer). Why not just create partial classes to store the business logic? Here is an example:
public partial class Product()
{
public static List<Product> GetGreenProducts()
{
using(MyEntities db = new MyEntities())
{
return db.Product.where(p => p.Color == "green").ToList();
}
}
}
Then, in the controller, I can do this:
public class ProductController : Controller
{
public ActionResult GreenProducts()
{
return View(Product.GetGreenProducts());
}
}
This approach seems 1) Very simple 2) Very clean 3) would allow for easy unit testing.
I think this is a relevant pattern. Can anyone identify any problems with this, or other thoughts?
There are two questions being asked here:
Why not extend EF classes with business log (as opposed to Controllers)?
Simple. Because business logic should not be coupled to EF anymore than it should be coupled to Controllers.
Essentially (and this is my interpretation of the OP's comment), why not put CRUD operations in EF as opposed to Controllers. Sample method given: UpdateLastModified does it belong in EF or a seperate Service?
UpdateLastModified is already far too coupled an example to begin with. You should not create a method to update a column on an entity. Do you also need UpdateCreatedBy, UpdateName, UpdateId? I sure hope not. EF gives you all the tools necessary to perform such trivial tasks.
The ProductService should be concerned with middle tier concerns, whatever they may be. Things like projecting the ProductEntity -> ProductDao and what have you. ProductService.UpdateLastModified should not exist.
I am working on a new project, and, after seeing some of the difficulties of previous projects that didn't provide enough separation of view from their models (specifically using MVC - the models and views began to bleed into each other a bit), I wanted to use MVVM.
I understand the basic concept, and I'm excited to start using it. However, one thing that escapes me a bit - what data should be contained in the ViewModel?
For example, if I am creating a ViewModel that will encompass two pieces of data so they can be edited in a form, do I capture it like this:
public PersonAddressViewModel {
public Person Person { get; set; }
public Address Address { get; set; }
}
or like this:
public PersonAddressViewModel {
public string FirstName { get; set; }
public string LastName { get; set; }
public string StreetName { get; set; }
// ...etc
}
To me, the first feels more correct for what we're attempting to do. If we were doing more fine grain forms (maybe all we were capturing was FirstName, LastName, and StreetAddress) then it might make more sense to go down to that level. But, I feel like the first is correct since we're capturing ALL Person data in the form and ALL Address data. It seems like it doesn't make sense (and a lot of extra work) to split things apart like that.
Appreciate any insight.
If you are using all the fields of the Person object, then there's nothing wrong with using a complex view model. However, if you are only using a field here or there, then it's much better to build your viewmodel with only those values you are using.
You can do your view models any way you like, but the whole point of having them is that a view model should be customized to the view it's representing.
It can also be a lot easier to use the first method if you're using something like AutoMapper to map to business or domain models, because the objects should have similar definitions.
You're not using MVVM. You're defining ViewModels, classes for only view purposes in order to avoid to break the Model classes. In that case you can define the properties you want for your best profit. In the example I will go for the second solution but it's up to you.
I'm working on a big project with many developer providers. In that case the customer let us to define the ViewModels that we want keeping the Models (Business Entities as they call) for their concern. Because we are different groups no one is worried about another ViewModels so you can even use one class for one view, no matter if another view is different a little bit from the first one. That's one of the advantages of ViewModels instead of pure Model using.
I prefer to define the ViewModels in client-side through JSON objects for the sake of data binding. With this you can truly use MVVM through knockoutjs, angularjs, backbonejs, etc....
If you want to use MVVM check knockoutjs. It's very easy and pleasant to use
Using Model classes directly or wrapping them (as in your 1st example) in your ViewModel class can be a potential security issue if your Model classes have some sensitive properties (i.e. IsAdmin in the User class).
Say your controller actions takes a PersonAddressViewModel input parameter:
public ViewResult someAction(PersonAddressViewModel personAddress)
{
//save it
}
A malicious user can basically set any property in your PersonAddressViewModel composite object even if your UI does not provide such capabilitiy.
This is made possible by the default binding mechanism of the MVC.
To avoid this, either don't wrap sensitive model classes or use the Bind attribute
More on this here: Pro ASP.NET MVC 3 Framework 3rd Edition By Steven Sanderson , Adam Freeman (Chapter 17)
If you're using that view model to render a form, I would vote for the second approach, since you're combining all the view data required for the form.
Im new to ASP.NET MVC, trying to learn the basics.
Im now trying to learn the relationship between the model ,view and controller.
The interaction between these three looks different, why? (Look at the arrows)
Source 1: MSDN
Source 2 (Page 65): Steven Sanderson
I would be glad if you help me sort out my confusion
Thanks
Edit:
What you are saying is that mvc can be implemented differently?
(Still asking about asp.net mvc - Not mvc in general)
I have been looking at the mvcmusicstore
and it looks like this.
Controller:
public ActionResult Details(int id)
{
var album = storeDB.Albums.Find(id);
return View(album);
}
Model:
public class Album
{
public int AlbumId { get; set; }
public int GenreId { get; set; }
public int ArtistId { get; set; }
public string Title { get; set; }
public decimal Price { get; set; }
public string AlbumArtUrl { get; set; }
public Genre Genre { get; set; }
public Artist Artist { get; set; }
}
view:
(Had to add as image, add code the normal way did not work)
This looks like the MSDN version, how would this be rewritten to fit Sandersons diagram?
Maybe this will help me understand!
Edit again:
Hi again
Let me sum this up. Please respond if I'm wrong.
The way Microsoft intended us to use mvc is the one we see in the above MSDN link and in MusicStore.
Then there are other "versions" of mvc such as Sandersons (or whereever it originates from).
So Microsoft give us a basic way of how to use the mvc framework, but it is ok to do it other ways.
A newbie should not get stressed by seeing different versions, sticking to the one seen in MSDN/MusicStore is perfectly fine.
The key difference is the inclusion of the "Presentation Model" in Sanderson's diagram. The ASP.NET MVC implementation often uses the Model as the Presentation Model, even though they can be different (and I would argue that they should be different, but it's a holy war and there's no need to get into that).
In most very simple ASP.NET MVC applications, the model is the data entity. Whether it's an EF entity or a Linq2Sql entity, makes no difference. This is because most applications are simple forms-over-data and the presentation is probably one-to-one with the persistence.
The MVC pattern itself, however, doesn't require this. In a more pure framework-agnostic form, Sanderson's diagram illustrates the fact that the controller is interacting with the model. The model is really the "gateway to the domain core" in this sense. Controllers and views are part of the application, but the model has the underlying business logic and, beneath that, layers of persistence and other infrastructure information (properly separated, of course) which are unknown to the application. The boundary between the controller and the model is the application boundary, the point at which other applications can also connect to the domain core and interact with it.
A presentation model is usually nothing more than a simple value object. It's not an entity of any kind in the sense that it doesn't have to exhibit any business behavior or maintain its lifecycle the way that a persistable business entity would. It's just a flat object with some attributes of data.
It can have some behavior, but that behavior is for the application and not for the domain core. For example, maybe it has some methods or properties that the view can use. The presentation model is part of the application, so it's presentation-layer-aware. Essentially it just holds data that the controller needs to pass to the view (or even receive from the request, depending on the framework).
In ASP.NET MVC you'll very often see the model used also as the presentation model. The same object may be playing two roles in those cases, but the two roles are definitely different.
Edit: Just noticed your updated question...
In that example, Album is playing the role of both domain model and presentation model. (In fact, I would argue that it's not a domain model at all because it's too anemic. Notice that it has no functionality, just bare data.) In a richer domain model, Album would likely have more functionality. For a contrived example, imagine that instead of auto-implemented properties it has properties which enforce business logic when set, and it has methods on it such as AddSong(Song song) and Play() and other such behaviors.
This richer model can still be used as a presentation model, but the functionality might not make sense in the scope of a view. A view is really suited more toward just bare data elements. The controller would interact with the model's functionality. So you might create a presentation model similar to the Album domain model in structure, and it would look just like the one in your example.
Going forward, what if the view needs other data as well? Maybe the view needs to know something about other models which aren't part of the same aggregate as Album. It wouldn't make sense to modify the domain models to accommodate the view. That's backwards. The presentation should wrap around the domain core, not the other way around. So you might add properties to the presentation model which are populated from other things inside the controller.
So you might end up with something like this...
Domain model:
public class Album
{
public int ID { get; private set; } // might need to be immutable
private string _title;
public string Title
{
get { return _title; }
set
{
// don't allow empty titles
if (string.IsNullOrWhiteSpace(value))
throw new ArgumentNullException("Title");
_title = value;
}
}
private Album() { }
public Album(int id, string title)
{
ID = id;
Title = title;
}
public void Play()
{
// some implementation
}
public void SomeOtherMethod()
{
// some implementation
}
}
As the business domain grows and changes, this model could change with it. The main point is that it changes at the behest of the domain core and the business logic, not at the behest of UI implementations.
A particular "page" on a particular website which uses this domain core may need specific information about an album, and maybe some other information as well. You'd tailor a presentation model to fit that:
public class AlbumViewModel
{
public int ID { get; set; }
public string Title { get; set; }
public string Owner { get; set; }
public IEnumerable<Listener> Listeners { get; set; }
public string SomeCompletelyUnrelatedValueNeededByTheView { get; set; }
}
The controller would then construct this presentation model for the view:
public ActionResult Details(int id)
{
// TODO: validate and sanitize any inputs
var album = AlbumRepository.Get(id); // after all, why bind the UI _directly_ to the DB? that's just silly
var someOtherObject = SomeOtherRepository.Get(someOtherValueFromSomewhereElse);
var albumVM = new AlbumViewModel
{
ID = album.ID,
Title = album.Title,
Owner = somethingElse.SomeValue,
Listeners = someOtherObject.GetListeners(album),
SomeCompletelyUnrelatedValueNeededByTheView = "foo"
};
return View(albumVM);
}
This is a much more manual approach overall. It's useful when you have more complex domain models, multiple complex applications interacting with that domain, different technology stacks throughout the domain, etc. For simple forms-over-data applications the standard ASP.NET MVC implementation usually works fine. Most of the tutorials for it reflect this, consolidating multiple responsibilities into fewer objects, using decorators instead of explicit code (assuming the use of the same stack of tools across the board), etc.
The examples you're looking at get you to a working application very quickly with very little code. As with any framework, it works beautifully if you do things the way the framework intends you to do them. If you need to step outside the bounds of the framework, you can still maintain the pattern in a more abstract and framework-agnostic way.
Edit: For your update again...
In a way, yes. ASP.NET MVC is a framework which borrows a lot from the MVC pattern in general. As with all things, there's more than one way to do it. Sticking with simple implementations and quick applications, the functionality provided by the ASP.NET MVC framework and explained in its various tutorials is perfectly acceptable and is a great example of the use of a framework... Using a tool to get a job done.
They stick to the pattern in all the most meaningful ways. At the same time, however, in the true nature of a framework (which is generally outside the scope of a pattern description), they try to give you tools which make very light work of the actual development. If you don't have a pressing need to separate your domain models from your presentation models, you don't have to. One model can play both roles. If you don't have a pressing need to abstract your data access behind, say, a repository pattern, you don't have to. You can throw together some quick Entity Framework functionality directly in your Models and be done with it.
Ultimately it's up to the needs of the project, the preferences of the developer(s), and so on. The patterns are more academic, the frameworks are more pragmatic. Balancing the two is the key.
I guess the distinction is that in asp.net MVC you can have strongly typed views which have 'knowledge' of your model and the entity being passed through to the view. In its purest sense though the View shouldn't (or rather, neednt) have any knowledge of the model. For that reason I say Steven Sandersons example is better.
Fantastic book by he way!
I wouldn't sweat it - Stephen Sanderson's diagram is showing less of the cycle but in more detail.
I'd interpret the MS article arrows as:
Controller populates model (from services, etc)
Controller directs to view
View populates through binding model
The microsoft diagram isn't really that useful or informative or useful though in my opinion. You could equally argue that arrows could go in different directions - or even in both directions like Sanderson's do. E.g. Controller also received models from binding, etc.
The Sanderson arrows are annotated well and are self-explicit, and the book is great.
In a controller, I do the following:
DBContext DB = new DBContext();
var u = DB.Users.Find(1);
u.firstname = "blah";
UpdateModel(u);
DB.SaveChanges();
I want to do the same from within a model...
namespace Project.Models
{
public class User
{
public void resetPassword()
{
// Generate new password, etc.
this.password = "blah";
}
}
}
Any idea how I go about doing this? It seems UpdateModel() is only available from within controllers.
I'm using EntityFramework Code-First CTP5.
I think UpTheCreek is correct but it probably needs some explanation so I'll try to expand on his/her answer. The first step would be to use the repository pattern. You can find many examples of this pattern in MVC with a google search - this is a particularly gentle introduction (about 3/4's down the page).
The walkthrough goes on to mention dependency injection, and that's something that's also worth looking in to. I tend to favor Ninject myself, however there are other dependency injection containers available.
Putting data access concerns in your model is not a good idea.
Update: Yes, you'd usually have a data access layer for this. As Andy says, the currently fashionable way to do this is using a repository. As a rule, you don't want anything in your model that is not core business logic.
I'm new to ASP.NET MVC, coming from a PHP MVC background. It's been kind of an awkward transition (see my question history, heh.)
One thing I like a lot in theory that's big in the .Net world is the idea of models being persistence agnostic. But in this case, what is the proper way to save changes to a model? In PHP, I'd just call $model->save(); after doing some transformation. In C#, I'm not sure of how to do that.
Is this appropriate?
public class AwesomesauceController
{
//inject!
public AwesomeSauceController(IDataAccess da)
{
DataAccess = da;
}
private readonly IDataAccess DataAccess;
[HttpGet]
public ActionResult Edit(int Id)
{
// PHP equiv: AwesomeSauceModel::find($id); Controller is unaware of DAL
return View(DataAccess.AwesomeSauces.Where( sc => sc.Id == Id).FirstOrDefault());
}
[HttpPost]
public ActionResult Edit(AwesomeSauce sc)
{
//persistence-aware version: model is aware of DAL, but controller is not
if($sc->valid()
$sc->save();
redirect();
}
else { return view(); }
// compare to persistence-agnostic version, controller is aware of DAL, but model is not
if(ModelState.IsValid)
{
da.Persist(sc);
return Redirect();
}
else
{
return View(sc);
}
}
}
I guess the only thing that strikes me as wrong about this is that typically, I wouldn't want a controller to be directly accessing a data access layer in this way. Previously, in PHP land, my controllers would access models and views only, basically.
What you are doing is fine. ActiveRecord vs Repository vs Home Brew DAL is an eternal question that we'll discuss forever.
The repository pattern is very popular in the .NET world right now and you'll probably see a lot of examples of its usage. MVC doesn't care what your data access strategy is though. Using whatever you find comfortable is just fine and a better strategy than using a pattern because everybody else is doing it.
It's OK for a model to have a Save() function, but you would usually want that Save() behavior to be independent of your model -- abstracted away to an interface.
Remember your design principles: design to an interface, not an implementation.
Another caveat is how do you test your pieces individually? If a model doesn't know how it's persisted, it can be tested based on what a model should do, and your persistence mechanism can be tested based on what it should do.
In any case, it looks like your Create() action is doing double duty -- trying to use the model to Save, then trying to use the DataAccess to persist. Are these two objects doing the same thing? Could this be confusing or unreadable/unmaintainable later on?