![]() But, the unfortunate part here is that I'm still pulling back all of the data for "thing" even though all I want to do is to check to see if "thing" exists. ![]() This makes the intent of the logic a bit easier to parse. the object doesn't exist in the persistence layer. getById() and then check to see if that method returned null (or threw an error, depending on the implementation): As I've gotten older, however, I've come to understand that this constraint is silly and artificial and, that my persistence APIs can contain as many methods in their interface as I find helpful to get the job done.Īt first - and for many years - I thought that all data abstractions had to conform to an interface that looked something like this:Īnd that, if my business logic needed data to process a command, it would have to make due with the data returned by these methods even, if these methods returned way more data than was necessary to fulfill the request.įor example, if I had a workflow that wanted to check to see if an object existed, I'd have to call. I believe that the Repository Pattern is a more specific type of Data Access Layer, relating to aggregate roots however, I tend to use the two terms interchangeably to refer, generally speaking, to the "persistence abstraction".Īs I was reading-up on these patterns, I came to believe that the API for these layers had to be kept simple, revolving primarily around CRUD (Create, Read, Update, Delete) methods. When I was first learning about Abstractions in programming, one of the early patterns that I came across was the Data Access Layer (DAL), which attempted to hide the implementation details of the underlying data persistence mechanism.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |