I am trying to get my head around lazy loading in an ASP.Net MVC app. For instance, I have a class with a property that is a collection (Employees). I want the collection to only load when I need it loaded:
public class Department
{
[DatabaseGeneratedAttribute(DatabaseGeneratedOption.Identity)]
public int DepartmentId { get; set; }
public string DepartmentName { get; set; }
[ForeignKey("DepartmentId")]
public Lazy<ICollection<Employee>> Employees { get; set; }
}
First, I am not sure if I should lazy load the class or the collection
public Lazy<ICollection<Employee>> Employees { get; set; }
public ICollection<Lazy<Employee>> Employees { get; set; }
I assume the collection.
Next, I cannot seem to find a related example to actually load the property/collection once I need it and after the class has been instantiated. I am also not sure if this is done in the class itself or in my MVC controller.
Any help is appreciated.
You don't have to use the Lazy<T> on your Employees property. You'll just be adding unnecessary "lazyness", since Entity Framework (and other ORMs like NHibernate) queries are already lazy, i.e.: the query will only hit the database when you explicitly tell it to.
So, by making Employees of type:
public virtual ICollection<Employee> Employees { get; set; } //make sure to mark it as virtual, otherwise it won't be lazy
When querying:
var result = myContextObj.Departments.Include(d=> d.Employees).Where(d=> d.Id == someID).SelectMany(d=> d.Employees);
The code above does nothing but create a Query Object representing the query that may be sent to the database.But it's not going to do anything, unless you "materialize" the result, either by doing a foreach on result, or calling ToList() for example.
For lazy loading you must:
public virtual ICollection<Lazy<Employee>> Employees { get; set; }. You actually miss the virtual that allows the framework to create the proxy by overwritting the property;
context.Configuration.ProxyCreationEnabled = true;, this is the defautl value.
I have a model that is defined in EF database first edmx. From there I expose some tables and views (mainly views). As it's possible to augment the EF model with OData, how could I add a navigation property of a complex type to another EF and OData exposed type?
Currently I define a partial class and add the properties and attributes using them. But it looks like it's possible to add the desired properties with OData's modelbuilder functionality too, or perhaps better yet, first use ODataConventionModelBuilder and then augment the results. Alas, I'm unable to stitch together a working example from the existing API documentation and examples I've found.
Here's the code
//This class is generated from a view by EF (edmx)...
public partial class AccountView
{
public System.Guid Id { get; set; }
public int CompanyId { get; set; }
}
//Here's augmenting the EF generated view with some additional data...
[MetadataType(typeof(AccounViewMetaData))]
public partial class AccounView
{
//This is added here explicitly. AccountView itself exposes just
//a naked key, CompanyId.
public virtual Company Company { get; set; }
//This is just in case...
public class AccounViewDomainMetaData
{
//This is to add a navigation property to the OData $metadata. How to do this
//in WebApiConfig? See as follows...
[ForeignKey("Company")]
public int CompanyId { get; set; }
}
}
//This is an EF generated class one from an edmx..-
public partial class Company
{
public Company() { }
public int CompanyID { get; set; }
public string Name { get; set; }
}
//How to add a navigation property from AccountView to Company so that it'd become
//possible to call http://example.com/Accounts?$expand=Company and http://example.com/Accounts(1)?$expand=Company ?
var builder = new ODataConventionModelBuilder();
var companySet = builder.EntitySet<Entities.Company>("Companies");
var accountSet = builder.EntitySet<Entities.AccountView>("Accounts");
accountSet.EntityType.HasKey(i => i.Id); //EF has hard time recognizing primary keys on database first views...
//How to hide this from the result if there's a way to create a ?$expand=Company navigation property?
//accountSet.EntityType.Ignore(i => i.CompanyId);
This is related to my other question regarding OData and models.
I have 3 domain models - Item, ItemProductLine, and ProductLine. Each of these map to already existing database tables. I also have a view model that I use in my view.
Domain models:
public class Item
{
public string itemId { get; set; }
public string itemDescription { get; set; }
public float unitPrice { get; set; }
// more fields
public virtual ItemProductLine itemProductLine { get; set; }
}
public class ItemProductLine
{
public string itemId { get; set; }
public String productLineId { get; set; }
// more fields
public virtual ProductLine productLine { get; set; }
}
public class ProductLine
{
public string productLineId { get; set; }
public string productLine { get; set; }
// more fields
}
View model:
public class ItemViewModel
{
public string itemNumber { get; set; }
public String itemDescription { get; set; }
public Double unitPrice { get; set; }
public string productLine { get; set; }
}
My current query is:
from item in dbContext.Items
where unitPrice > 10
select new ItemViewModel()
{
itemNumber = item.itemNumber
itemDescription = item.itemDescription
unitPrice = item.unitPrice
productLine = item.itemProductLine.productLine.productLine
}
I currently have this query in the controller, but I am refactoring the code. I want to put the query code in a repository class in a data access layer. From what I've read, I should not reference any view models in that layer. If I change select new ItemViewModel() to select new Item(), it will return the error:
The entity or complex type 'proj.DAL.Item' cannot be constructed in a LINQ to Entities query.
A solution I have seen is to create a data transfer object (DTO) to transfer data from my domain model to my view model.
However, by doing this, I would have 3 copies of the data. If I need to add another database field and display it, I need to update 3 files. I believe I am violating the DRY principle. Is it inevitable to violate the DRY principle when using DTOs and view models? If not, can you provide an example of how to refactor this to have DRY code?
Having multiple models is not a DRY violation however your code breaks the Separation of Concerns principle because the domain model is the same with (or built upon, read: coupled to) persistence model. You should keep your models separated for each layer and use a tool like automapper to map them. This prevents the model to serve more than one purpose.
It looks like repeating yourself, but in fact you are keeping your layers decoupled and ensuring code maintainability.
Unlike ramiramulu, I would refrain from introducing too many abstractions.
If you use EF, your DAL is actually Entity Framework, no need to abstract that. A lot of people attempts to do this but this only complicates your code a lot, for no gain. If you were doing SQL requests and calling stored procedures directly, then a DAL would be helpful, but building an abstraction on top of EF (which is another abstraction, or over NHibernate) is a bad idea.
Also, pure DTOs as an abstraction are more and more frown upon, but they can be used if you have a middleware and do not directly access the database - for example, a message bus like NServiceBus: messages would be considered DTOs in that case.
Unless you do very simple and pure CRUD (in which case, go ahead, put the logic in controllers - no reason to add complexity for pretty straightforward business), you should move business logic outside of your controllers for sure. For this you have many options, but 2 of the most popular are : a rich domain model with domain driven design or rich business services with service oriented design. They are a lot of ways to do this, but these 2 illustrates very different approaches.
Rich Domain (Controller per Aggregate)
In the first case, your controller would be responsible for acquiring the domain object, calling the logic, and returning a View Model. They do the bridge between the View world and the Model world. How to acquire the domain object(s) needs to be somewhat abstracted, often simple virtual methods works great - keep it simple.
Aggregate Root:
public class Item
{
public string itemId { get; set; }
public string itemDescription { get; set; }
public float unitPrice { get; set; }
// more fields
public virtual ItemProductLine itemProductLine { get; set; }
// Example of logic, should always be in your aggregate and not in ItemProductLine for example
public void UpdatePrice(float newPrice)
{
// ... Implement logic
}
}
View Model:
public class ItemViewModel
{
public int id { get; set; }
public string itemNumber { get; set; }
public String itemDescription { get; set; }
public Double unitPrice { get; set; }
public string productLine { get; set; }
}
Controller:
public class ItemController : Controller
{
[HttpGet]
public ActionResult Edit(int id)
{
var item = GetById(id);
// Some logic to map to the VM, maybe automapper, valueinjector, etc.
var model = item.MapTo<ItemViewModel>();
return View(model);
}
[HttpPost]
public ActionResult Update(int id, ItemViewModel model)
{
// Do some validation
if (!model.IsValid)
{
View("Edit", model); // return edit view
}
var item = GetById(model.id);
// Execute logic
item.UpdatePrice(model.unitPrice);
// ... maybe more logic calls
Save(item);
return RedirectToAction("Edit");
}
public virtual Item GetById(int id)
{
return dbContext.Items.Find(id);
}
public virtual bool Save(Item item)
{
// probably could/should be abstracted in a Unit of Work
dbContext.Items.Update(item);
dbContext.Save();
}
}
This works great with logic that trickles down and are very model specific. It is also great when you do not use CRUD and are very action-based (e.g. a button to update only the price compared to an edit page where you can change all item values). It is pretty decoupled and the separation of concerns is there - you can edit and test business logic on their own, you can test controllers without a backend (by overriding the virtual functions), and you do not have hundreds of abstractions built on one another. You might roll out the virtual function in a repository class, but by experience you always have very specific filters and concerns that are controller/view dependent, and often you end up with one controller per aggregate root, so controllers are a good place for them (e.g. .GetAllItemsWithAPriceGreaterThan(10.0))
In an architecture like that, you have to be careful about boundaries. For example, you could have a Product controller/aggregate and want to list all Items related to that product, but it should be read-only - you couldn't call any business on Items from Products - you need to navigate to the Item controller for that. The best way to do this is to automatically map to the ViewModel :
public class ProductController : Controller
{
// ...
public virtual IEnumerable<ItemViewModel> GetItemsByProductId(int id)
{
return dbContext.Items
.Where(x => ...)
.Select(x => x.MapTo<ItemViewModel>())
.ToList();
// No risks of editing Items
}
}
Rich Services (Controller per Service)
With rich services, you build a more service oriented abstraction. This is great when business logic spawns multiple boundaries and models. Services play the role of the bridge between the View and the Model. They should NEVER expose the underlying Models, only specific ViewModels (which play the role of DTO in that case). This is very good when you have a MVC site and some REST WebApi working on the same dataset for example, they can reuse the same services.
Model:
public class Item
{
public string itemId { get; set; }
public string itemDescription { get; set; }
public float unitPrice { get; set; }
// more fields
public virtual ItemProductLine itemProductLine { get; set; }
}
View Model:
public class ItemViewModel
{
public int id { get; set; }
public string itemNumber { get; set; }
public String itemDescription { get; set; }
public Double unitPrice { get; set; }
public string productLine { get; set; }
}
Service:
public class ItemService
{
public ItemViewModel Load(int id)
{
return dbContext.Items.Find(id).MapTo<ItemViewModel>();
}
public bool Update(ItemViewModel model)
{
var item = dbContext.Items.Find(model.id);
// update item with model and check rules/validate
// ...
if (valid)
{
dbContext.Items.Update(item);
dbContext.Save();
return true;
}
return false;
}
}
Controller:
public class ItemController : Controller
{
public ItemService Service { get; private set; }
public ItemController(ItemService service)
{
this.Service = service;
}
[HttpGet]
public ActionResult Edit(int id)
{
return View(Service.Load(id));
}
[HttpPost]
public ActionResult Update(int id, ItemViewModel model)
{
// Do some validation and update
if (!model.IsValid || !Service.Update(model))
{
View("Edit", model); // return edit view
}
return RedirectToAction("Edit");
}
}
Controllers are only there to call the Service(s) and compose the results for the Views. They are "dumb" compared to domain oriented controllers, but if you have a lot of views complexities (tons of composed views, ajax, complex validation, json/xml processing along side html, etc.), this is the preferred approach.
Also, in this case, services do not have to related to only one model. The same service could manipulate multiple model types if they share business logic. So an OrderService could access the inventory and make adjustments there, etc. They are more process-based than model-based.
I would do it this way -
My Domain Model -
public class Item
{
// more fields
public virtual ItemProductLine itemProductLine { get; set; }
}
public class ItemProductLine : ProductLine
{
// more fields
}
public class ProductLine
{
// more fields
}
DAL Would be -
public class ItemRepository
{
public Item Fetch(int id)
{
// Get Data from Database into Item Model
}
}
BAL would be -
public class ItemBusinessLayer
{
public Item GetItem(int id)
{
// Do business logic here
DAL.Fetch(10);
}
}
Controller would be -
public class ItemController : Controller
{
public ActionResult Index(int id)
{
Item _item = BAL.GetItem(10);
ItemViewModel _itemViewModel = AutomapperExt.Convert(_item); // something where automapper will be invoked for conversion process
return View(_itemViewModel);
}
}
Automapper will be maintained in a separate class library.
The main reason why I choose this way is that, for a particular business there can be any number of applications/frontends, but their business domain models shouldn't change. So my BAL is not going to change. It returns business domains itself. Thats doesn't mean everytime I need to return Item model, instead I will have MainItemModel, MiniItemModel etc., all these models will server business requirements.
Now it is the responsibility of frontend (probably controllers) to decide which BAL method to be invoked and how much data to be used on frontend.
Now some devs might argue, that UI shouldn't be having that judgement capacity to decide how much data to use and what data to see, instead BAL should have that power to make decision. I agree and that happens in BAL itself if our domain model is strong and flexible. If security is main constraint and domain models are very rugged, then we can have the automapper conversion at BAL itself. Or else simply have it on UI side. End of the day, MVC is all about making code more manageable, cleaner, reusable and comfortable.
I've got a couple questions regarding DBContext and achieveing my desired Results.
I can retrieve data like this
---Model
public class InvoiceModel
{
[Key]
public int? Invoice_Number { get; set; }
public decimal Amt_Total { get; set; }
public decimal Amt_Due { get; set; }
public decimal Amt_Paid { get; set; }
public List<InvoiceModel> GetInvoice()
{
using (VuittonEntities db = new VuittonEntities())
{
return (from inv in db.Invoice
select new InvoiceModel
{
Invoice_Number = inv.Invoice_,
Amt_Total = inv.AmountTotal,
Amt_Due = inv.AmountDue,
Amt_Paid = inv.AmountPaid
}).ToList();
}
}
--- Controller
public ViewResult Index()
{
var data = new InvoiceModel().GetInvoice();
return View(data);
}
This is pretty much standard LinQ and it returns my Invoice table with the 4 fields I selected. But now I want to achieve this using DB Context. So I added this new Class to my controller and called it in the view like this.
Controller
public class VuittonEntities : DbContext
{
public DbSet<InvoiceModel> Invoice { get; set; }
}
View
public ViewResult Index()
{
VuittonEntities db = new VuittonEntities();
return View(db.Invoice.ToList());
}
It returns the Entire table and I have to comment out my List'InvoiceModel' class
Assumptions:
VuittonEntities is my Connection String Name,
Invoice is the table
Vuitton is my .edmx class --
I heard that this can be achieved without having to use a Select Statement. It appears I am not linking my model class to a LinQ entity but when I add my context class, it throws errors on my inv."FieldName" columns in my List{InvoiceModel} Class.
TLDR Version:
How Can I return selected fields from DbContext Class instead of entire table
Why does adding a DBContext class raise errors on my List(ModelClass) fields
If you don't want the entire table, then don't just call ToList() on the DbSet, as that will just grab all of the table as you have seen.. You had it right when using Select, since the Select statement is meant to create a projection from one set of data into a new form (new class, model, anonymous object).
I am creating this MVC model and trying to understand best way to do it.How should I get related data when I have relationships between tables.For example in code below I have created a formviewmodel and I am calling function to get all images in Images table for a user. Should I instead keep images property of Users model and fill that within LINQ query in repository instead of calling a method from the Model? Is there a way in LINQ to autofill all images for the contact?
public class UserFormViewModel {
UucsrRepository repository = new UucsrRepository();
public User User { get; set; }
public SelectList States { get; private set; }
public SelectList Genders { get; private set; }
public List<Images> UserImages { get; set; }
public UserFormViewModel(User User) {
User = User;
UserImages = repository.GetUserImages(User.Id).ToList();
States = new SelectList(repository.GetAllStates(), "ShortName", "Name");
Genders = new SelectList(repository.GetAllGenders(), "Gender", "Description");
}
}
Thanks !
First it typically does not make sense to store the actual repository object in the viewmodel. That violates the tenent that you should only send the view exactly what it needs and nothing more. They way i typically create the viewmodels is to ahve a very basic wrapper with almost no code in it. Most of the logic to fill the VM is done in the controller using the repository pattern.
Your example is clear enough to understand how you should or should not be using view models.
Kevin correctly noted, that the ViewModel should only contain the data you use in the view for presentational purposes. In your case, depending on what the view does, you might only send a subset of your User properties. For example, if you just show some user information, but not modify it, you don't need to send the user ID. I would go with smth like:
public class UserFormViewModel
{
public string UserName { get; set; }
public string Email { get; set; }
...
public SelectList States { get; private set; }
public SelectList Genders { get; private set; }
public List<Images> UserImages { get; set; }
}
To populate (prepare) the ViewModel it's rather convenient to use a separate helper method:
private UserFormViewModel PopulateUserFormViewModel(int userId)
{
var model = new UserFormViewModel();
var user = repository.GetUser(userId);
model.UserName = user.Name;
model.Email = user.Email;
...
model.UserImages = repository.GetUserImages(userId).ToList();
...
return model;
}
And in your action you call:
public ActionResult ShowUser(int userId)
{
// maybe do something else
var userFormViewModel = PopulateUserFormViewModel(userId);
return View(userFormViewModel);
}
That's just one of the possible ways, but the general principles are pretty clear: keep your ViewModel simple (just the data you need in the view) and preferably create a reusable method for converting your domain object into your ViewModel.