I am trying to get my head around business entities that you want to list in a grid or list where a user will pick one to edit/view.
Lets say I have an Entity that have a lot of properties and collections, but my Grid will only display like 2 properties to the user. Besides using lazy loading on collections what would be the best / efficient way to load this data and display to the user?
I am thinking of creating a DTO object with the required properties and pass that to the UI. But I am worrying about over populating DTO's.
To do maintenance on an object you could allways use a Property Grid control if your are in c#.
With this you can view/edit collection and everything else.
Related
We develop the back office application with quite large Db.
It's not reasonable to load everything from DB to memory so when model's proprties are requested we read from DB (via EF)
But many of our UIs are just simple lists of entities with some (!) properties presented to the user.
For example, we just want to show Id, Title and Name.
And later when user select the item and want to perform some actions the whole object is needed. Now we have list of items stored in memory.
Some properties contain large textst, images or other data.
EF works with entities and reading a bunch of large objects degrades performance notably.
As far as I understand, the problem can be solved by creating lightweight entities and using them in appropriate context.
First.
I'm afraid that each view will make us create new LightweightEntity and we eventually will end with bloated object context.
Second. As the Model wraps EF we need to provide methods for various entities.
Third. ViewModels communicate and pass entities to each other.
So I'm stuck with all these considerations and need good architectural design advice.
Any ideas?
For images an large textst you may consider table splitting, which is commonly used to split a table in a lightweight entity and a "heavy" entity.
But I think what you call lightweight "entities" are data transfer objects (DTO's). These are not supplied by the context (so it won't get bloated) but by projection from entities, which is done in a repository or service.
For projection you can use AutoMapper, especially its newer feature that I describe here. This allows you to reduce the number of methods you need to provide "for various entities" (DTO's), because the type to project to can be given in a generic type parameter.
I hope someone can give me some guidance in how to best approach this situation.
I am using dbcontext, wpf and sql server.
I am having situations were the presentation of the data requires other data than just what is coming from a single table. For example, if I had a person table but wanted to show also how many books they had read from related data, say fields would be name, address, NoOfBooks.
I currently create a new class, called say PersonBookPM, that I fill up with data from a linq query which combines the two tables which includes the above three fields.I create an observablecollection of that and make that the itemssource of the grid/listbox.
When I am then adding data to that I then need to use the selecteditem, convert that back to the single entity of person, and attach it back in to the context.
It seems like the classes have already been defined by the code gen and I am repeating the process only slightly differently.
Am I going round the houses here?
Thanks Scott
I want to pass data to views, and I've two options in my mind (if you know a better approach, please mention).
I am using Zend_Based ORM system, and coded in a way that if I add a new field in database, its automatically available within the model.
1st: I convert the model's data into array and pass the array to the view. This way I will have all the data available within the view, but model's function/operations will not be available. And incase I need specific functionality, i will be coding view helpers while there are chances that the same functionality is already coded within model. e.g. a getting a date in specific format.
2nd: Or I pass the complete model object to the view, this way I will have all the model's functions available, but view will be able to access model's save function which is a bad thing. I can add some more functionality within model to make it read-only, but it will be extra work.
any suggestions which approach is better.
According to the MVC principle it's perfectly fine to let the View allow access to the Model. So, pass the complete Model to the View.
By the way, passing arrays around will copy your data (by value), while passing objects around will not (by reference). (Assuming PHP5). Large arrays might affect your performance.
I've recently refactored my application with the following:
Linq to SQL db connection
Objects to wrap the linq to sql classes
Mappers to map back and forth between objects and Linq to Sql entitys
Service layer to call the repository, handing up objects to the UI.
Before I was just using Linq to SQL objects in my UI (I know). But when displaying relations it was so easy. For instance:
I have a able called SchoolProfile, and a table called School. A user has a SchoolProfile (with GPA, Rank, etc..) , which links to a School. The School adding functionality was easy - because it has no foreign keys.
When creating a form for a user to list all SchoolProfiles - they dont want to see a SchoolId. Before in my view it would simply be schoolprofile.School.Name. Now a ShoolProfile is a "flat" object in my ViewData with no properties. I guess I could create other classes to get the related data (name of the school, etc..) but that feels messy. Any suggestions?
My suggestion is to look at ViewModels and AutoMapper. Basically you will create a specific ViewModel for your View and you can include SchoolName as a property of that ViewModel. Then you can use AutoMapper to map from your Domain Model (form Linq to Sql) to your ViewModel easily.
Basically, you want your View to get all the information it needs from the ViewModel. So design your ViewModel based on all the info you need to display. So all it needs to do is take what is in the ViewModel and spit it out.
I'm completely new to M-V-VM and very new to Silverlight, just reading about it for the first time today. As a sample, I am creating a model containing a list of items. My (Silverlight 4) View contains a listbox and my ViewModel will look to the model to retrieve the collection that the listbox will bind to.
My question is this. I think it would be good to use an ObservableCollection to hold the items that the listbox binds to. This would be an ObseravleCollection in the ViewModel. Should I also use this type of collection in the model, or should I use another collection type and do smoe conversion between model and viewmodel?
There are 3 basic scenarios (in order of increasing complexity):
model simply provides an access to a backend services and does no caching of data flowing through it at all
model exposes a collection of items, vms don't have their own collections, and then views are simply bound to collection in model object
model exposes a data source, vms have their own collection that serve as window into this data source, and views are bound to collections in vms.
In first case you'd use List to simply pass a requested data to vms, in other cases you'd use ObservableCollection so that either views will be properly updated via binding (case #2) or vms can properly update its own collections (case #3)
the usual way of doing this is to use IList/List or something similar in the model and then do a conversion in the ViewModel. So in the model you will have something like IList and in the ViewModel you convert it to ObservableCollection (usually in the ViewModel's constructor).
Cheers, Alex