Bit of an abstract problem here. I'm experimenting with the Domain Model pattern, and barring my other tussles with dependencies - I need some advice on generating Identity for use in an Identity Map.
In most examples for the Data Mapper pattern I've seen (including the one outlined in this book: http://apress.com/book/view/9781590599099) - the user appears to manually set the identity for a given Domain Object using a setter:
$UserMapper = new UserMapper;
//returns a fully formed user object from record sets
$User = $UserMapper->find(1);
//returns an empty object with appropriate properties for completion
$UserBlank = $UserMapper->get();
$UserBlank->setId();
$UserBlank->setOtherProperties();
Now, I don't know if I'm reading the examples wrong - but in the first $User object, the $id property is retrieved from the data store (I'm assuming $id represents a row id). In the latter case, however, how can you set the $id for an object if it has not yet acquired one from the data store?
The problem is generating a valid "identity" for the object so that it can be maintained via an Identity Map - so generating an arbitrary integer doesn't solve it.
My current thinking is to nominate different fields for identity (i.e. email) and demanding their presence in generating blank Domain Objects. Alternatively, demanding all objects be fully formed, and using all properties as their identity...hardly efficient.
(Or alternatively, dump the Domain Model concept and return to DBAL/DAO/Transaction Scripts...which is seeming increasingly elegant compared to the ORM implementations I've seen...)
You would use the setId function if you are controlling the IDs, if you want to override the data store ID, or if you want to update/delete the data without having to retrieve it first (i.e. already have the ID from a POST).
Another alternative would be calling setId() to reserve an ID by "querying" (insert a record) the data store for the next available ID.
It's not really relevant what the ID is set to until you actually need to use it to reference something. Calling setId with no parameter would do nothing except flag the object as new data. Once you actually try to "get" the ID is when one would be generated. Sort lazy ID generation.
Related
Once I have loaded a domain object from the database I have the key to some of its related objects. For example, when I load an "Organisation", I know the ID of the related "Owner".
I want the Owner property to be lazy loaded, since there's no guarantee I'll be using it during the request or session.
So, the way I see it, the Organisation object could either:
Have an OwnerId property and an Owner property. The Owner property would only be filled on demand (using OwnerId for the lookup). In this case, the only (small) challenge is keeping the two properties synchronised; or
Have an Owner property only. This would initially contain the key (integer) to lookup the Owner. If the Owner is called upon, the value would be replaced by an Owner object. In this case, the (small) challenge would be to avoid type-casting problems.
Which approach is best? Any why? Or are there other approaches? Something else I'm missing?
I'm using PHP, with domain, mapper and service layers. Your thoughts are much appreciated!
I am using Option 1 (see above) and it's panning out fine.
An Entity (let's say a UserEntity) has rigid rules for it's properties, and it can exist in 2 states - persisted (which means it has an id) and pre-persisted (which means it does not have an id yet).
According to the answer to this question about how to handle required properties, a "real" UserEntity should only ever be created with an id passed in to its constructor.
However, when I need to create a new UserEntity from information sent by the browser, I need to be able to validate the information before persisting into the db.
In the past, I would simply create a blank UserEntity (without an id), set the new properties, and the validate it - but, in this new, more secure way of thinking about Entities, I shouldn't ever create a new UserEntity without its id.
I don't want to create TWO places that know how to validate my UserEntity's properties, because if they ever change (and they will) it would be double the code to update and double the chances for bugs.
How do I efficiently centralize the validation knowledge of my entity's properties?
Note
One idea I had is reflected in this question, in which I consider storing the non-state properties like email, password and name in a standardized value object that would know about the rules for its properties that different services, like the Controller, Validator, and Repo, or Mapper could use.
that's what factories are for. to the factory method you pass only the data that is required to enforce the real invariants of UserEntity (take some time to figure out what are your real invariants of UserEntity and you'd better do it with your domain experts).
in the factory method you create a new Id and pass it to the UserEntity constructor.
In this stage i don't think it is that bad to discard the instance if the validation inside the constructor fails. in the worst case - you've lost an id... it's not a case that suppose to happen quite often - most of the time the data should be validated in the client.
Of course another option is that in the factory method you first validate the parameters and only then create a new Id and pass it to the UserEntity constructor.
itzik saban
I think you have a couple of options to consider:
(1) Consider your first comment:
An Entity (let's say a UserEntity) has rigid rules for it's
properties, and it can exist in 2 states - persisted (which means it
has an id) and pre-persisted (which means it does not have an id yet).
Here, you are already mention that validation actually depends on whether the entity has been persisted. In other words, if the entity hasn't been persisted, then it should be valid without the ID. If you continue with this domain specification, I feel the validation should act accordingly (e.g. return isValid even without an ID if the object hasn't been persisted)
(2) If you assume "valid" means the object has an ID, then you would need to generate the ID upon creation. Depending on how your IDs are generated, this could get tricky (e.g. save to database and return created ID, or generate unique identifiers somehow, or ...)
Using either approach, its probably worth implementing common base class(es) for your Entity (e.g. with ID) to help minimize duplicating validation across the different states. Hopefully, this shields the derived entities from the common validation as well.
In my opinion , save() , and load() methods should be doing both validation and setting ID attribute . And by the way an entity without Identity attribute is not a entity at all .
In my view Identity attribute should be validated and ensured when entity is in transit e.g
loading from db , loading from file or (after) saving to db such that
if loading from db fails discard the entity saving to db/file fails discard the entity .
Since validation is business log /behavior etc and a better pattern for that would be
Strategy Pattern (http://en.wikipedia.org/wiki/Strategy_pattern)
The topic of how to do validation correctly is somewhat of a grey area.
Validation is typically cast as Invariant and Contextual validation. Invariant validation pertains to those things that, according to your problem domain, have to be present in order for your model to function properly in its intended role. Contextual validation pertains to state that's valid within a given usage context (e.g. A Contact used for emailing needs an email address, but doesn't need phone number; a Contact used for catalog mailings needs a mailing address, but doesn't need an email, etc.).
If you want to be architecturally pure, then technically the concerns of input validation (what your customers are typing into a user interface) and the state of a given entity are two different concerns. Ideally, your domain should have no knowledge of the particular type of application it's written for and therefore shouldn't be burdened with providing error messages suitable for use, either directly or indirectly, in displaying error messages back to the user. This presents a bit of an issue, since it can lead to duplicate or triplicate error checking (client side, service side, domain-level), so many opt for a more pragmatic approach of dealing with most validation external to the entity (e.g. validating an input model prior to entity creation).
I don't see the problem with persisting invalid data. What is valid or not is a business concern and can sometimes depends on the situation. The database doesn't care about these business rules.
If I have to fill out a big form online and the very last step requires me to enter my credit card information and I don't have my card ready, I'll have to discard all that information and the next time enter it all over again (which won't happen because I rather go somewhere else). I would like that application to store the information I already gave and later on I can make it functionally valid. As long as it isn't valid, I can't order things online.
I'm looking for best practices to fetch users created content.
I have $user object form 'security.context' and I need to get single record created by this user by some $record_id,
so what I should do?
$this->getDoctrine()->getRepository('AcmeRecordBundle:Record')
->findOneBy(array( 'id' => $record_id, 'user' => $user->getId() ));
This doesn't look good to me, because I have lot's of information that needs to be fetch looking for user too(to don't let other users try get it by some id). And for any content( personal photo, some other private content) I have to pass 'user' => $user->getId() ?
Or it's better to create UserRepository with all these functions? getRecordById($id), getPhotoById($id), getPrivateInformationById($id), etc.
I was working with Rails a little, and there I was able to define current_user method
def current_user
return #current_user if defined?(#current_user)
# ....
end
and then just use it as
current_account.records.find(params[:id])
is there any possibility to make it work like this with Doctrine2 and Symfony2? Like
$user->getRecords()->find($recordId)
In any situation you have to specify user which you pass to your function, which deal with the fetching logic inside custom repository as specified in official documentation for Doctrine.
Of course you have to pass the user's id for the "WHERE" sql clause, just because ROR did it magically behind the scenes (which is a very bad practice imo), doesn't mean it didn't do it at all.
As for the other matter, both solutions are ok:
Fetch data from the particular repository, and pass the object id + the user's id, or:
Create methods which internally get user's id and put them in queries
And remember that user's id is fetched only once during the request, so don't worry about getting it from the security context too much.
You need to implement Symfony 2 ACL features. This allows you to specify ownership for "domain objects" (individual instances of DB classes) and what kind of access users have on a domain object. Then you can use for example the JMSSecurityExtraBundle and implement access controls based on object ownership. Once implemented your users won't be able to modify each other's objects (by parameter manipulation) and you won't need the additional parameter in your queries.
Here are a few relevant links:
Access Control Lists (ACLs)
JMSSecurityExtraBundle
Personally I found the repository classes to bloat things a bit in a small to mid-size application. Not sure what your approach is, but most everything I've read (and what I went w/ in a recent Doctrine 2 app) was to have a 'service' layer which manipulated the entities. This is b/c in D2, implementing save / delete etc in the entities undermines the purpose of the system which is to alleviate knowledge of persistence from the entities and treat them as Plain Old Php Objects (TM) ;)
The thing that looks odd to me about your query is passing an primary key id and a User id to fetch a User. Seems to me like the pk of the User table would be the user id, or at the very least if the user id isn't the pk (not sure why that would be) you should be able to get the records w/ just the pk. Here's the method to fetch a User object in my system
/**
* #param int $iId user id
*
* #return object
*/
public function fetch($iId)
{
return $this->_oEm->find('AwesomeApp\Entity\User', $iId);
}
The current user sort of function you're looking for should be related to the session in your application. In zf I've created a session handler that persists the doctrine User object to session storage, then when the session is read I re-attach the User object to the Entity Manager. You probly want to do something similar in sf, then a 'getCurrentUser' call would return the same User object as pulling it from the database. Storing a User object in the session prevents the need to go back to the database for it on every page load, for example if you just stored the User id in the session.
At the end of the day you're 'supposed' to put complex select queries into repositories, but this is obviously left to User discretion when it comes to best practices. In this case, when you have just a pk, I'd say there's no point to writing a repository class.
All,
Building a small web app using PHP. I don't have much programming experience.
In my app, I have created a class to access DB records which I call DAO_DBrecords. The class includes basic functions to create new records, update existing records, etc. Currently, the class satisfies all my DAO needs for all my DB tables. In the functions, I pass as one of the argument a string that represents the DB table (users, articles, etc).
At this point I could do either of 3 things:
Use this class throughout my program whatever the type of record (i.e., table) I'm dealing with.
Create specific classes for each type of record (e.g., DAO_Users), which inherit from DAO_DBrecords but are otherwise empty.
Create specific classes for each type of record (e.g., DAO_Users), which inherit from DAO_DBrecords and specify the DB table the class can access via a variable (e.g., private $table = 'users'). In the parent class, the variable would be null, or an empty string.
Again, at this point I am not envisioning the need for table specific functions (but that might change).
Which of those (if any) is the right approach?
Thanks,
JDelage
Edit: I have edited option 3 which previously read:
3. Create specific classes for each type of record (e.g., DAO_Users), which inherit from DAO_DBrecords and specify the DB table the class can access via a constant (e.g., const TABLE = 'users'). In the parent class, the constant would be null, or an empty string.
I will choose the 3rd option. In DAO_Users you can eventually put methods to do specific things on the user record itself (for example, create and store a salted password, send verification email, fetch all user's friends from the database as DAO_Users collection, fetch all user's comments, etc).
In this way you can both use a DAO pattern and organize all app "actions" in classes by action target.
I have built into our ORM layer object caching. Basically a hash of the SQL query is used as the key and the value contains the collection of objects from the DB resultset. However this creates a problem if one of the objects in the resultset is updated the cached resultset does not include the updated object. There is no write consistency. How would I implement write consistency?
Thanks
UPDATE: Currently I have an ObjectWatcher class that handles what objects are cached and their keys. Objects are cached with retrievable keys so for Person class it's Person.101 for example. The SQL query is hashed and the key maps to a Dependency object which within it has a list of the dependent objects. So SELECT * FROM person might return a Dependency object from APC which maps to Person.101 and Person.102 the resulting collection is built from this Dependency object. This works fine for the update of a single object. So If I update Person.101 and put the newly update object into APC overwriting the stale one, when a older query is run that updated object will get put into that result set, which could be incorrect. I need a way to clean not only the object from memory but all the Dependency object which hold a reference to the updated object. In APC is there a way to search for keys containing or values containing or filter keys and values?
This question is not related to APC.
You need to manage, how data will be stored in APC (or any other storage). If you want to update value of key in APC, when object will be changed - it can be possible, only when Object will know the key (hash of query) and this object should be able to collect all data from another objects, fetched by that query. All it sounds like absurd idea.
Any model should be designed with Single Responsibility principle, so if you want to cache whole objects (it's not very good idea too), then create unique keys for each object.
Also, objects shouldn't care about how they will be stored (cached), and where. So you need one more object, which will manage objects caching.
And I recommend to cache not whole objects, but only values of records in DB, which are takes to many time to fetch them from DB.
But if you still want to use hash of SQL query as a key, then you can use tags and write "names" of objects in these tags.
For example, if in result-set you have objects Person, Employer and Customer, then key will have tags "person", "employer" and "customer". And, when object Customer will be changed, you can delete from cache all keys, which marked with tag "customer".
But, anyway, it's not a responsibility of Customer object, all this things should be managed by another object.
Question was edited, so I'll edit my answer too :)
Tags is not the part of APC, is the part of wrapper. Tags is very useful thing and very handy for your case.
which hold a reference to the updated object
Tags can be this reference. You don't need to search keys by tag, you need just to remove all keys associated with that tag (to keep data actual), and this wrapper has existing method to do it.
In examples:
Let we have query SELECT * FROM persons WHERE email <> '' - cached result of this query will be marked by the tag "person".
So, when we will update any Person object, we will remove all keys, which are marked with tag "person", so our result for query SELECT * FROM persons WHERE email <> '' will be removed, and in next request our script will generate new (actual) value.