Populating Data Model Properties
-
I'm developing a WPF app using MVVM. I have created a Models project and a Data Layer project. They are two seperate projects because later on I'm going to move the data access into a WCF service. The Data Layer creates, populates, and returns model objects. The question is, assume a one to many relationship such as an invoice header and invoice line items. The InvoiceHeaderModel has a list property of type InvoiceDetailModel. Where's the right place to populate this? If you do it in the model, maybe with lazy loading, then you create a dependency between the Model project into the Data Layer project. The Data Layer project knows about the Model project, but not the other way around. And, if you lazy load the child properties, then you have code in the models. The only other place I can see it would be to have a method in the DL, say GetInvoiceDetails(InvoiceHeaderModel Header) that gets the details for the invoice and populates the header model's details property. What do you think?
Everything makes sense in someone's mind
-
I'm developing a WPF app using MVVM. I have created a Models project and a Data Layer project. They are two seperate projects because later on I'm going to move the data access into a WCF service. The Data Layer creates, populates, and returns model objects. The question is, assume a one to many relationship such as an invoice header and invoice line items. The InvoiceHeaderModel has a list property of type InvoiceDetailModel. Where's the right place to populate this? If you do it in the model, maybe with lazy loading, then you create a dependency between the Model project into the Data Layer project. The Data Layer project knows about the Model project, but not the other way around. And, if you lazy load the child properties, then you have code in the models. The only other place I can see it would be to have a method in the DL, say GetInvoiceDetails(InvoiceHeaderModel Header) that gets the details for the invoice and populates the header model's details property. What do you think?
Everything makes sense in someone's mind
This is how I would do it: The WCF application will have the model project and will serve the same responsibility through parsers or whatever you like to call them. Parsers will translate the return value from the database to a specific object. This object will then be returned to the front end. The front end, will still have it's own MVVM. Here the data layer (or some other name) will make calls to the service operations and will translate the service model to the UI one. I have assumed that the UI model is different from that in the services. Hope this makes any sense.
"Your code will never work, Luc's always will.", Richard MacCutchan[^]
-
This is how I would do it: The WCF application will have the model project and will serve the same responsibility through parsers or whatever you like to call them. Parsers will translate the return value from the database to a specific object. This object will then be returned to the front end. The front end, will still have it's own MVVM. Here the data layer (or some other name) will make calls to the service operations and will translate the service model to the UI one. I have assumed that the UI model is different from that in the services. Hope this makes any sense.
"Your code will never work, Luc's always will.", Richard MacCutchan[^]
I was thinking that I could pass a bool into the GetInvoices method on the data layer that determines whether or not the invoice details property gets populated. This way I could get back either a list of invoices with all details, or just a simpler list of headers only. And, with this design, all the code is in the data layer instead of the models. What do you think?
Everything makes sense in someone's mind
-
I was thinking that I could pass a bool into the GetInvoices method on the data layer that determines whether or not the invoice details property gets populated. This way I could get back either a list of invoices with all details, or just a simpler list of headers only. And, with this design, all the code is in the data layer instead of the models. What do you think?
Everything makes sense in someone's mind
-
Sounds good to me. Model should not be doing that work at all. :)
"Your code will never work, Luc's always will.", Richard MacCutchan[^]
Completely agree. Model should only be in charge of representing the data, and probably relationships between entities, let the ViewModel and Presenting interfaces translate the data according to their needs.
"Whether you think you can, or you think you can't--either way, you are right." — Henry Ford
-
I'm developing a WPF app using MVVM. I have created a Models project and a Data Layer project. They are two seperate projects because later on I'm going to move the data access into a WCF service. The Data Layer creates, populates, and returns model objects. The question is, assume a one to many relationship such as an invoice header and invoice line items. The InvoiceHeaderModel has a list property of type InvoiceDetailModel. Where's the right place to populate this? If you do it in the model, maybe with lazy loading, then you create a dependency between the Model project into the Data Layer project. The Data Layer project knows about the Model project, but not the other way around. And, if you lazy load the child properties, then you have code in the models. The only other place I can see it would be to have a method in the DL, say GetInvoiceDetails(InvoiceHeaderModel Header) that gets the details for the invoice and populates the header model's details property. What do you think?
Everything makes sense in someone's mind
I have 2 major project in my Silverlight apps. WCF with the model and the dal (controller). The models have no relationships, they don't even have adorners yet but that will change. The model does however have all the fields from a view rather than a table. The DAL does all the decision making. All access is via stored procs (this maybe old school for some but it is the way I work) and most selects return a view (this being and extended table and matches the model). The second project is purely UI with view and viewmodel folders (among others). I also have a utilities project that is used across projects and is still in constant flux. I am continually finding that the standard controls all seem to be missing something and therefore we have moved to the Telerik control suite which I highly recommend (expensive and it adds 1mb+ to the silvelight client download).
Never underestimate the power of human stupidity RAH