問題描述
ASP.NET - 加載具有重 OO 結構的網格數據 (ASP.NET - loading grid data with heavy OO structure)
Let's say I have an object that is fairly complex. Since it is so complex, it takes a bit to load from the database. Now let's say my users want a grid that shows all of these objects, and I know if I provide it the performance will not be desirable. I'm trying to put my finger on the best way to handle this. So far I have two ideas:
Implement lazy-loading: I really don't need the entire object to display the grid. I'm not sure I want to go this route those because everywhere else will need the entire object loaded and I don't want to drastically change my architecture for grids.
Return a recordset specifically tailored for my grid: This is the way I am leaning. Basically I would return a DataSet or simply flat object. My Stored Procedure can do the data relations to return the recordset as desired.
Is there any other approaches I might want to look at? I haven't done any real grids previously and wanted to make sure I did it right the first time. Can anybody come up with any disadvantages of my second idea?
參考解法
方法 1:
I think your intuition is correct that your second way is more correct. When your complete object is so large that it's a significant load to load it, you're right to try to minimize the overall load by reducing the size of the data returned. It sounds like your object may benefit from a bit of refactoring as well, however; if it's truly that large that it's such a hassle to load, could it benefit from refactoring it into smaller components?
方法 2:
I would create a light entity that represents the fields you need to display in your grid.
BUT! I would only do that if the grid is read-only. If you need to alter objects from this grid, then you end up with an awkward translation layer which could end up being no better for performance. In that case, I would lazy load you domain objects. There are other ways you can squeeze some better performance out of that data pull, like DB tweaks (indexes, checking fragmentation of the indexes, etc. Just check the execution plan after you write the query).
You could also implement pagination in your proc if you are returning a large list of these heavy objects so that you only get 10 or 20 at a time, and the user has multiple pages to browse. Rather than load the entire list and page in the code, you could add a column for rownumber and pass the row number start and end that you want to pull as parameters to the proc.
(by Mike Cole、Paul Sonier、Andy_Vulhop)