I am trying to develop three tier architecture.
Data Access Layer:Will have methods for Connection String, Executing Store procedure, Executing Select query etc. Most cases, this will return Data Set
Business Layer: Can Access Data Set from Data Set & provide sorting & filter data to the Web Forms.
Presentation Layer: Will have all web pages, user controls (if any). This Layer can access only Business Layer
This works OK for me till requirement was only limited to display records. However, when it comes to paging or sorting, each time i have to bind fresh data, resulting in unnecessary Database Hits. To avoid this,i have stored Data Set into cache & typecasting it to Dataset objects. Is there any other alternatives for the same
I done with binding Grid with List objects & not with Dataset. I Have initialized List for the first time to get required Data.
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 am writing an ASP.NET application with a SQLServer database in which I have to calculate rates for members of my application. These calculations affect more than 10 database tables.
I believe I have two options :
In the data access layer, fetch the data for a member from the first table in the database and return it to the business layer. Once there, perform some calculation on the fetched data to generate new data to be saved in a second table. Finally, call back into the data access layer to save the result. Afterwards, repeat this whole process, pulling information from the second table to calculate results to be saved in a third table, and keep doing this for all necessary tables.
Use a stored procedure to encapsulate calculating and saving the new rates for a member in the correct tables within a database transaction.
Which option do you think is best and why? If I use the first option, how should I perform all of the inserts and updates in one ADO.NET transaction from the business logic layer? I am currently barred from using an ADO.NET transaction outside of the data access layer.
IMO it depends on how much priority needs to be given for performance and modular design.
If this was a trading application where I would have to calculate the prices instantaneously from different tables, I would use a stored procedure
Better performance for certain amount of load but when it gets too much queries, then a distributed database becomes essential
One disadvantage is that if you want to move to a different database in the future (in most cases people don't), then you have to port the stored proc to the new ones
The other option I would have is to keep most of the values in a distributed cache (like memcache) and do the calculations in a business layer.
The values will be pre-populated into the cache and the cache will be refreshed as and when there are changes.
This gives flexibility in terms of removing the database dependency.
But it seems to me that your operations are quite heavily DB dependent in functionality and suggest a stored procedure route. If you think the second option of cache is possible, it is worth a try.
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 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.
how can i store different data enetered using multiple steps?
Its 4-5 step procedure, user can go through each step & at the final submission i want to store it in database.
I want to create class to store this data & store the data in object of that class & use it from session.
I just want to know what type should i use to store multiple data.
i.e. array,ienumrable,list,etc..
Any suggestion or example to implement class like this.
Thanks
Pragnesh
List is generally most useful. If the data items map to specific fields though you could just make them properties in the class (you could use reflection if you wanted to make the code generic).
Alternatively for a wizard you could use the built in wizard control, which stores all the field data in viewstate. This is generally better than storing in session - for example if the user opened two browsers it would get confused.
Depends on how many data you need to maintain between steps and how many visitors will use the steps concurrently - server resources are limited.
The ways to use:
Session state (may be lost, but uses server resources)
Viewstate (can't be lost, but uses traffic)
Regarding types to use - use types that are not complex and are compact after serializing, more primitive. Test it.