I need some help thinking about the design for my business objects.
Our database records the daily entry and exit times for the comings and goings of the employees in our company. Each record also stores the UserID of the employee, the ID of the work station the employee signed in at and obviously the date.
A user can have many Entry and Exit times at any number of work stations at any given date.
The record looks something like this:
SignInID | UserID | WorkStationID | DateTimeEntry | DateTimeExit
I have a reportviewer on my asp.net form that must display reports of this entry and exit data grouped by date, work station or user.
For example it must display all data for a specific date (and within that, ordered by work station).
Or it must display all data for a given work station (and within that, ordered by date) and other similar formats.
Until now I had a monstrosity of a method where I selected the data and constructed some kind of makeshift datatable to display on my form.
I now want to redesign using objects, but I don't know how to design the hierarchy i.e. what object contains the collection of entry and exit times, and how to I make it flexible enough that I can query it (using Linq, perhaps?) based on the various display criteria?
I'm really interested in learning more about designing objects and using the correct terminology for what I'm trying to do, so if you can point me to some articles explaining these concepts it would be very helpful too.
EDIT: Okay, at least I've learned something new. What I'm trying to do is ORM - Object-relational mapping - and .NET has an inbuilt ORM tool called Entity Framework. So far so good. Now I have to see whether it can help me figure out how to organize my data.
Well, I actually have to thank the community for not answering my question, because I got to learn a lot about Entity Framework, Linq (and its limitations with Entity Framework in .NET 3.5) and a whole bunch of other things to answer my own question.
What I ended up doing was create an Entity Model of my Database using Entity Framework and thus created the Business Objects I needed to organize my data. I learned that my data isn't designed in a hierarchy, rather there are associations such as Workstation and User that each time entry records contains. I used a Linq-to-Entities query to select the data I wanted and flattened it out using its associations (example Time.Workstation.Name or Time.User.FullName) so that in the end, my projected object contained all the data I wanted in each row of my report. My projected object was actually a POCO I created for the purpose of holding the queried data and making it available as a datasource for my rdlc report.
Finally I bound the results of my query to a Reportviewer's ObjectDataSource which connects to the rdlc file that I was able to define to my liking: i.e. Either displaying the Workstation first or the User, or whatever associated information I wanted to display.
Related
The project I am currently working requires retrieving/searching from large amount of data, the flow as below:-
Enter a keyword and search from about 500,000 members
Retrieve only top 6 members.
Allow sorting based on the member country or gender.
Requirements: Using EF5.0
The data is currently displayed using a UserControl and DataBinded using Repeater, will be updated through an UpdatePanel with next, previous button, etc.It is preferably but not limited to using EF5.0, and I am opened to other options (e.g. SqlDataReader) and cast it back to the members object manually.
My current solution calling the Entities with skip by using the page number, i.e.
members = context.Members.Where( conditions here ).Skip(page number * size).Take(size);
My question will be: Is my strategy the industrial / common ways of doing it? Anyone with similar experience can share with me in terms of performance / optimization, is there any other better way to do so?
I got really good performance using a stored procedure, instead of a LINQ query. This saves performance because of the query metadata generation/sql translation. If you are returning a large result set, disabling change tracking is a good option too.
I am using database paging which uses ROWCOUNT check it here https://web.archive.org/web/20211020131201/https://www.4guysfromrolla.com/webtech/042606-1.shtml and it gives really good performance with 200000 records including sorting and paging.
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 want to use ASP.NET Dynamic Data for my next project, but there is a problem a can't manage to solve. In the database we manage authorization on a per-row basis. For example no user is permitted to see all rows of the Contracts table. So there is a Many to Many Relationship between Contracts and Users. So everytime Dynamic Data performs a Select to show all Contracts it has to look into the ContractUsers junction table to see what contracts the current user is permitted to see (filtered by UserID which will be stored in a session variable). Of course these junction tables should be invisible to the users.
By default Dynamic Data returns all rows of a table, so is it possible to customize this behaviour for every query the user performs?
I want to use Dynamic Data together with LINQ to SQL but if this task would much easier to accomplish using Entity Framework I would look into that too.
Thanks for your help and time.
Implementing such a solution in Dynamic Data it will probably require the creation of a custom Entity Template; not really easy but once done it will not require the creation of custom pages just the editing of the page templates.
I think it will be really usefull to check the excellent work on DD done by S.J.Naughton and presented on his blog.
Greetings, F.
You should not use dynamic data because you need full control over querying and manually write all linq queries to add your data level security. If you still insist on dynamic data be aware that you will still write most of pages yourselves and you will only use dynamic templates. You will have to manually define ever data source and correctly pass where condition to filter results based on logged user.
In addition linq-to-sql is not able to hide junction table and entity framework is able to do that only if junction table contains just two FKs for many-to-many relation. If this table contains any other column you want to use in the application you will have to map it as any other entity and dynamic data will show it as an entity.
Dynamic data are technology for quick creation of simple application where you need to provide access to database through web interface but what you describe is not a simple scenario. You need per record authorization which can differ among entity types.
For typical examples I see of SqlDataSource, LinqDataSource...
EVERY example deal with how to make changes to a Customer table where the Gridview/RADgrid directly represents the customer..
But in my case I have stored procedure which show data from multiple tables and make changes to multiple tables so it seems I am not a candidate for uses declarative data sources?
Or can anyone point me to an example?
Why not? If you can define single data object which will be used as result from GetCustomer procedure and input to StoreCustomer procedure you can wrap calling these procedures into some class and use ObjectDataSource. Your ASP.NET application doesn't have to know nothing about internal storing of Customer in database. The only requirement is to have flat object = no 1:N or M:N related data.
Not sure how to word the question...
Basically, so far all my SQL stuff has been stored procedures and dumped into a gridview. The odd case where I had to perform an action based on a value (such as highlighting a row green if a certain value was true) were done as the gridview was rendering in one of the overrides.
Now however I have to do something far more complicated - pull three sets of data down, run a series of checks on all three and some date related checks and stuff, then populate a gridview with some of the items.
In logic terms, I want to run three queries, and store the lists of results (presumably in Lists?) then run some logic, then populate the gridview.
Specifically what I don't know how to do is:
Best way of pulling the data, and putting it into a List or other datastructure that lets me easily run through it, and retrieve data based on column (myList.age, or more likely, myList["Age"]).
One I have compared the data, I assume I create a new list that will be put into the gridview... how do I put the contents of a list INTO a gridview? How would I add other stuff such as buttons or checkboxes at the same time?
Any nudge in the right direction would be appreciated! Particularly doing cool stuff with lists and sql (if there is anything cool you can do with them)
There are actually several ways to do this with .Net without using an ORM solution. Instead trying to list all of them here I will link you to an article series that should help you accomplish what you want. The following series of articles is about N-Layer design, and includes answers to the information you are looking for. The first set of 4 articles were created some time ago with ASP.Net 2.0 then the author updated them with an additional six articles using ASP.Net 3.5
http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=476
If you want to avoid having to write SQL query and concentrate on the data instead, go with the Entity Framework. It's quite well integrated with VS. It will connect to your SQL database, you will tell it which tables to import, and it will create a series of classes for you to talk to your database.
Queries are quite easy to do, and they will return lists of objects which should be easy to manipulate and put to a grid later on.
You can create datatables and populate them using the lists that you have generated and then bind your grid using the newly created tables as the datasource.