This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Probably a newbie question... Why use MyUnitOfWork.FindById<MyEntity>? Or any of its sibling Find methods? What about just query MyUnitOfWork.MyEntities? Is there a reason for it? Performance/caching? |
|
|
|
|
You mean as opposed to a query on the Id property? Offhand, I can think of three reasons: First, FindById goes to the unit of work and cache first and the database second. (Find always goes to the database first, because it's running a query.) If we already have the entity with that ID, it saves querying the database to find the record whose Id equals such-and-such. In theory, we don't need a separate method for this because we could analyse the query to determine if it was an equality query on the Id property, but... Second, FindById is more intention-revealing. If we're receiving an ID via a query string, or pulling it out of session state, or getting it from an ItemActivated event, or whatever, it says clearly to the reader "I'm getting the item with this ID," as opposed to "I'm getting all the items that match ID = blah." The reader doesn't need to parse a query like Find<MyEntity>(Entity.Attribute("Id") == theId)[0]. Which reminds me that... Third, FindById returns a single entity (or null), which saves you having to index into a list of results (and check that the list actually contains something). More convenient, and the error checking is also more intention-revealing (checking against null instead of checking a count). |
|
|
|
|
Thanks! |
|
|
|
