Often web application have a database. Let say in this database there is for a table "user" . What I see often is that the developer creates a ORM class to get the data out of the database. "user" class for example is just a container for data from the database.
That's not what I do. "user" is a encapsulation of the behavior of a user. All code that does something with the user is inside the "user" class. ORM is added because the data is often stored in the database. I always define 2 classes: A "users"/"userlist" class (collection of users) and a user (individual user). The "users"/"userlist" class also representing the table and "user" representing the individual records (for example checking of the password is correct).
What I have noticed that many ORM (like ActiveRecord) system don't make the distinction between table and individual record. There is just one class "user".
My question is as follows:
Are there any ORM systems which makes a distinction between table and record (like the users/user in above example)
How do you use ORM, only for accessing data from database or for real oop.
If a ORM doesn't make distinction between table and record, where do you place code which processes multiple records
What do you think is a good way to combine oop and ORM?
An ORM class represents a single record and the entirety of those records represents the table. I don't think there is a need for a class that represents the table. What you commonly have in edition to the individual records is a service (e.g. UserService) that deals with operations on multiple objects.
Related
I know that each time a user registers in my ASP.NET MVC application the ApplicationUser class is used to create the new record and put it in the database.
I was wondering if it's okay to add properties to that class for example I want the model to have a column in the database for DateOfBirth. Then use that class(model) directly in my application when I have to do some business logic things, database queries and similar stuff. Or is it more correct to create a new table in the database called let's say ApplicationAccounts, that saves the general info about the account. Each ApplicationAccount will be associated with a ApplicationUser(1 to 1 relation) and be somewhat of a buffer in the communication with the real accounts. Does that make sense?
I would go with the second option : create your own table, link them up in a one to one relationship using the UserID as a unique foreign key and then go from there.
One note here, it is perfectly normal for the model you need for the views to be different from the database model, this is because your db model can hold a lot of data that your view doesn't actually need. You might want to consider having separate models and use something like Automapper for a quick translation from one to another.
I know SQL, but I'm not terribly experienced with it. I have a system in which I would like to log user logins, logouts and other security-related events in an indexed database to be able to pose manual queries to it, and I figure some SQL-based RDBMS should be the best fit for the job.
However, the records I'd like to store have similar, but not identical, data. All records would store a timestamp and a username, but the other data items would differ. For instance:
A login event would store the IP address the user logged in from, along with an ID for the created session.
A logout event would store the session ID but not the IP address (since I don't have access to the IP address at the point of logout).
An email-change event would store former and new e-mail address of the user.
How should one model something like this in a relational database? I can imagine at least three possibilities:
Use different tables for each kind of data item
Add columns for all the different data items and leave them as NULL for records that don't use them
Use one central table with the common data items, and auxiliary tables that store the rest of the data, linking to an event ID in the central table
Clearly, each one has its own advantages and disadvantages. I do realize that this is a somewhat subjective question and is also likely to depend on actual use-cases, but I imagine there ought to be standard/best practices for this kind of thing that I just haven't seen. Are any of my suggestions reasonable or standard? Is there some other option that I have missed that is better?
The solutions you mention appear in Martin Fowler's book Patterns of Enterprise Application Architecture. You might like to read that book to see what he says about using these patterns.
Use different tables for each kind of data item
Concrete Table Inheritance
Add columns for all the different data items and leave them as NULL for records that don't use them
Single Table Inheritance
Use one central table with the common data items, and auxiliary tables that store the rest of the data, linking to an event ID in the central table
Class Table Inheritance
Fowler also covers a fourth solution for this problem:
Serialized LOB
I've not really used access for a while and not too sure how best to proceed with this data model:
I have set of resource tables of differing type, eg: Data, Literature, Contractors, etc.
I also have a set of category tables such as Procedures, Topics, and Regions.
I need to create many-to-many relationships between the various resources and the various categories so it is possible to view a resource record and see lists of the various categories to which the resource is allocated, and vice-versa, that is to view all resources allocated to a specific category.
I realise that I could create lots of link tables, eg: LnkDataProcs, LnkDataTopics, etc, however with perhaps 10 resource tables and 3 category tables I would wind up with 30-odd link tables which seems wrong (it may also be useful to query all resources from each category anyway so it would be good to have one link table for each category).
I've done this kind of thing before using SQL in custom DB client apps by using one link table with fields as follows: CategoryTable, CategoryID, ResourceTable, ResourceID - So that the link table stores the table name as well as the foreign key.
However I'm not too sure how to fit this kind of model into an access database, it would be nice to use the Access framework (master-child form objects) rather than having to write loads of custom code to perform queries and populate forms.
Any ideas how to proceed, or even what this kind of relationship is called?
I want to build an online form builder much like wufoo that allows the users to create and publish their own web forms. Each submission should be saved to a data base where the user can later retrieve the submissions.
As these forms will be dynamic, ie. the user has complete control over the amount and type of form fields I am trying to think of a solid database design to store this information.
I would have one table fieldtype which contains every type of field available to the users, ie. textfield, emailfield etc.
One baseform table which will hold each forms id, url etc.
I would then have a table formfields which would contain ref to the baseform and to fieldtype, this table could also include custom validation to be done on each field.
Is this design good as a base structure? I imagine it will be easy to add new types of fields to the application however I don't know what the potential downsides are as I am far from a sql expert.
store user defined data in SQL
I think you are looking for the Entity–attribute–value database model in which:
The basic idea is to store attributes, and their corresponding values,
as rows in a single table.
Typically the table has at least three columns: entity, attribute, and
value. Though if there is only a single relevant entity, e.g. a table
for application configuration or option settings, the entity column
can be excluded.
See this pages as a start:
Using Database Metadata and its Semantics to Generate Automatic and Dynamic Web Entry Forms (pdf)
Planning and Implementing a Metadata-Driven Digital Repository (pdf)
I retagged your question with entity-attribute-value tag, in which you can browse a lot of threads that relate to your case.
As Mahmoud Gamal writes, The model you describe is "Entity/Attribute/Value"; as Borys writes, there are many known problems with this model.
As an alternative, you might consider storing the form entries in a "document" - e.g. XML or JSON - within a relational model.
For instance, you might have a table along the lines of:
FORM_SUBMISSION
--------------------
Submission_ID (pk)
Client_ID (fk to clients table)
Submission_date
SubmissionDocument
I'm using "client" to represent the users who create the form; to retrieve all submissions for a given client, you use a where clause on client_id.
This model makes it harder to run SQL queries against the form submission (though that becomes hard with EAV too when going beyond very simple queries), but it dramatically simplifies the persistence solution.
I am deciding how I should create an entity which I pull from a 3rd party api. The concept of my entity requires two API calls, one of which pulls the unique data about the entity, and the other which gives me a full schema of all possible data that could belong to an entity.
I've already written a repository for the entity, but where does the schema map fit in the domain layer if I'm only going to grab it once?
How should the entity hold this schema data?
I'm not familar with the mapper pattern, but does that seem like this is the right use case for it?
If you have schema data and then data then you're dealing with an entity with dynamic properties, akin to a dictionary or hashtable, but with validation.
You could treat the schema data as an entity of its own, that provides the knowledge level to instantiate and validate entities, which lie on the operational level.
Take a look here (pdf) for many related patterns.