FrankMonroe wrote:
LLBLGenPro v5.2
Using Derived Model DTO: Say I de-normalize a field (eg Order table has an EmployeeID fk to Employee table with EmployeeName and I create an Order DTO with the EmployeeName); now I use the DTO in my code... say the client updated the EmployeeID and I save it ... the EmployeeName is not changed - I need to reload the DTO from the database to get the good EmployeeName.
In other words:
//order contains a new, modified EmployeeID (but the old EmployeeName)
using (var adapter = new DataAccessAdapter())
{
var metaData = new LinqMetaData(adapter);
var entity = metaData.Order.FirstOrDefault(OrderPersistence.CreatePkPredicate(order));
if (entity == null) return Request.CreateResponse(HttpStatusCode.NotFound);
entity.UpdateFromOrder(order);
adapter.SaveEntity(entity);
// If I do not add the following line, order contains the new EmployeeID but the old (wrong) EmployeeName.
// If I have the line, then order contain the new (right) EmployeeName (the one attached to the new EmployeeID)
order = (from o in metaData.Order where o.UID == order.UID select o).ProjectToOrder().ToList()[0];
}
Q1) Is this by design or is this a setup somewhere? Is there a way to automatically have the entity always reloaded? For example there may be columns calculated in the database by a trigger when a line is updated and we need the new values in the DTO every time we do an update to the database.
Denormalized fields aren't updated in a DTO, that's by design. Your code assumes that if you update the entity it will magically update the DTO as well, but that's not the case: DTOs are projection results from a query, you can alter the data inside them, and use that data to change entities fetched from the DB, but the DTO isn't updated in that process: you have to re-project a query again to DTOs.
Q2) Perhaps I am not using this feature the right way? If that is the case, could you educate me please?
You're using the feature as intended The DTO's life ends when it's used to update an entity. You should then toss it away and fetch a new version for another cycle.
Q3) The way I described the Derived Model (denormalizing the EmployeeName): is this the typical use-case for Derived Models ? Is this why Derived Models were designed ?
Thank you!
Among other reasons, yes. It's a way to create a different model, projected from an entity model, for a different use-case than entities, where you don't need the entity code (e.g. you return them from a service so they're converted to JSon). In most cases, DTOs are used in read-only scenarios, e.g. for data for views in MVC.