I have a business logic layer object for my customers. It has a lot of different fields, around 100: Id, Name, and other fields.
I'm retrieving the customers un a data grid (RadGrid). Obviously in the grid I'm just retrieving a few fields.
The question is: if the business logic layer object has too many fields, even if I don't show all of them in the data grid, is it going to slow down the page? do you think it'd be a good idea to create another object for my customers for the lists?
Thanks
It wil take extra time to populate the server side list, but the key consideration is teh amount of data passed to the clinet, especially as a copy of the data will probably go into viewstate as well and when submitting the form this data will come back (through viewstate)
Rather than create a new object you could just use LINQ on you business objects to reduce the amount of data to pass forwards.
Related
Upon attempting to populate a grid on the UI layer, the UI asks the BI layer for a list of results, EF returns the list of each result, and they are cast into a DTO that pulls in some additional information, this is converted to a list and returned to the UI layer.
The performance is impossibly slow. EF is creating a new context and hitting the DB for each individual result. This is because the DTO class will create a new dbcontext each time it is initialized if it is no longer open/active. Finalization of the class closes out the context. I believe this is what is killing performance.
Is there any way to batch something like this? In SQL i would performance a JOIN on the tables i need to get the resulting data loaded into a dataset. In EF when i create the DTO i then access the mapped objects relations and access data from other objects as such.
How should I access a large amount of records via EF to be returned to a UI layer grid when i need to access some information that is not stored in that particular entity object? (an example of this would be having a relation between users -> customers via the customer_userID -> userID PK. And wanting to display the User's Name, once i have the Customer object i need to then query the User object for the Users name in relation to that ID.
Anyone have any articles that can point me the correct way?
Functions that were passing a large amount of data to the UI layer were causing the issues. Often because the object from the DB layer had to have some operations performed on it before it could be passed to the UI layer. In essence some of the list generating functions were causing the store to create a new context for each individual request.
Just-in-time paging was one performance boost, so as to request a starting offset and a record count. What is important to note there is we had to create functions to simply return the total counts so the UI grids knew how many records they were dealing with.
The next fix was on the functions that apply BI rules to the objects before they are passed to the UI layer. In these cases we open a new context and pass that into the function, so it uses that context and only closes it out after the results are all completed.
I have a simple ASPNET MVC list view which passes a custom built model object.First time through I need to go out to the server and return a list of objects and display on the view.
I am building the view to allow sorting by different columns, searching and paging, and I have written all the code for this. However every time I am going to the server and pulling the data.
Can I cut down on these DB roundtrips by using the list that I obtained first time ?
If so how do I pass it from the view back to the controller?
Viewdata, Tempdata - or pass the formcollection perhaps?
Take a look at http://www.knockoutjs.com this will give you a lot of functionality to manipulate the list in the browser and keeping the view in sync.
But it really depends on how big your list of objects is. If the quantity of data is large it is actually a more practical solution the way you implemented it already.
Actually, if you go back to your controller you'll be going to server.
I supose you really mean that you don't want to requery again your database to obtain data filtered, sorted and paginated and would like just to sort or paginate data from your model view classes with data alreay on the view.
Keep in mind that this type of operation doesn't have to be always better than requerying your database, as you'll be sending more info through the net back to the server and, usually, programatically sorting of list-like elements are operations less optimized than sorted retrievals from database.
The critical decision here will be between the cost of your database query and the size of your listview element. If your query is light and gets (or can get) many results, sorting it will be more expensive than requerying, while if your query is complex and usually throws few results then, effectively, it will be more efficient to sort data without requerying database.
Try to create a new controller method for the sort, this method will receive as a parameter your list view model class, and you'll need, somehow, to send back to your server that info. I usually use AJAX calls where I pass data as JSON to the controller.
I know, I know; don't store objects in session state. But...
Sections of our web application allow a user to define all sorts of criteria for viewing the results of data analysis:
sorting (multiple columns)
multiple filters
highlight criteria
column selection
I want to keep all these criteria handy as the user comes and goes to the analysis pages. I currently have objects that have lists of each type of criteria.
Here are my options:
"Flatten" the object model, storing only the attributes of all the different criteria that I need. My concern with this option is that there could be many (dozens and dozens) of attributes.
The classes are all marked as serializable. I could just plop them in session state and retrieve when needed. (Blech)
Serialize the objects myself to something like JSON and store the JSON string in session.
Has anyone tried something like the third option and had success with it?
I have an ASP.NET data entry application that is used by multiple clients. The application consists of multiple data entry modules that are common to all clients.
I now have multiple clients that want their own custom module added which will typically consist of a dozen or so data points. Some values will be text, others numeric, some will be dropdown selections, etc.
I'm in need of suggestions for handling the data model for this. I have two thoughts on how to handle. First would be to create a new table for each new module for each client. This is pretty clean but I don't particular like it. My other thought is to have one table with columns for each custom data point for each client. This table would end up with a lot of columns and a lot of NULL values. I don't really like either solution and suspect there's a better way to do this, so any feedback you have will be appreciated.
I'm using SQL Server 2008.
As always with these questions, "it depends".
The dreaded key-value table.
This approach relies on a table which lists the fields and their values as individual records.
CustomFields(clientId int, fieldName sysname, fieldValue varbinary)
Benefits:
Infinitely flexible
Easy to implement
Easy to index
non existing values take no space
Disadvantage:
Showing a list of all records with complete field list is a very dirty query
The Microsoft way
The Microsoft way of this kind of problem is "sparse columns" (introduced in SQL 2008)
Benefits:
Blessed by the people who design SQL Server
records can be queried without having to apply fancy pivots
Fields without data don't take space on disk
Disadvantage:
Many technical restrictions
a new field requires DML
The xml tax
You can add an xml field to the table which will be used to store all the "extra" fields.
Benefits:
unlimited flexibility
can be indexed
storage efficient (when it fits in a page)
With some xpath gymnastics the fields can be included in a flat recordset.
schema can be enforced with schema collections
Disadvantages:
not clearly visible what's in the field
xquery support in SQL Server has gaps which makes getting your data a real nightmare sometimes
There are maybe more solutions, but to me these are the main contenders. Which one to choose:
key-value seems appropriate when the number of extra fields is limited. (say no more than 10-20 or so)
Sparse columns is more suitable for data with many properties which are filled out infrequent. Sounds more appropriate when you can have many extra fields
xml column is very flexible, but a pain to query. Appropriate for solutions that write rarely and query rarely. ie: don't run aggregates etc on the data stored in this field.
I'd suggest you go with the first option you described. I wouldn't over think it. The second option you outlined would be a bad idea in my opinion.
If there are fields common to all the modules you're adding to the system you should consider keeping those in a single table then have other tables with the fields specific to a particular module related back to the primary key in the common table. This is basically table inheritance (http://www.sqlteam.com/article/implementing-table-inheritance-in-sql-server) and will centralize the common module data and make it easier to query across modules.
I am developing an ASP.NET 2.0 website. I have created data access and business logic layers. Now in the presentation layer I am returning data from the business layer as a dataset.
My question is whether to use a dataset or object collection (for example a Category object representing the Category table in my database). I have defined all classes that are mapped to database tables (Common objects). But there are situations where I need all of the records from the category table in the presentation layer. I am just confused. What should I do?
You don't want to return datasets, you want to return objects.
Generally when you have a data access layer and a business logic layer you will also want to have an entity layer. The entity layer will be an in memory repersentation of the database result set. If you return one row from the database you load one entitiy object. If you return more than one row, you will load an entity for each row, and return a collection of entities to be consumed by the presentation layer.
If you're using .net 2.0 and above for example, you can create generic collections of the entity type and easily bind different types of controls to these collections.
Hope this is helpful for you.
I would recomend returning objects or IEnumerable/IList etc of objects.
Depending upon your DB access you can populate a list of category objects manually or using something like LINQ2SQL or ADO.NET Entity framework very quickly, and if required cache them.
I've used both methods depending on the situation. If you only need to display the data from a table in a grid, the dataset(or datatable) method isn't terrible because if fields are added to the table they will automatically appear in the grid...assuming you are auto populating the grid with the columns. I look at this method as more of the quick and dirty method.
I would not return datasets at all. You are tightly coupling you service to you database. In the future when you database evolves you will be forced to change anything that uses the datasets. You want to create an abstraction layer between the database and the service.
I'd go with an object/collection solution. So if you are returning one row from a table you have one object, if you are returning several you'd use a generic collection. Generic collection will avoid a boxing/unboxing hit.
[edit]seems I was beaten to it[/edit]
You should create an entity layer, having classes representing each table in database. And then return lists of those classes.