'Reasons for and against objects handling their own persistence [closed]
I am looking at different options for persistence modelling in Windows Phone using Isolated Storage. One of the ideas I have come up with was the concept of each object handling its own (were it makes sense of course) persistence, rather than making a repository or other such entity for the purpose of saving objects.
I can't seem to find any good information on this method of persistence which leads me to believe I may have stumbled onto an anti pattern of sorts.
Has anyone approached persistence in this manner? If so what are your for's or against's in relation to this approach.
Solution 1:[1]
There are several undeniable truths in software development:
- A prototype becomes a product before you know it.
- An app targetted "just for platform-x" will soon be ported to platform-y.
- The data-store will change. Probably as a result of #2.
There are more ( :) ) but these are enough for to answer your question:
Go with a respository so your objects can be tested, know nothing about persistence, and you can swap out data stores (even go over the wire!) Might as well plan for that up-front.
Solution 2:[2]
Sounds like you're talking about the Active Record pattern? It works for some folks but there are criticisms against it (mostly from a testability / separation of concerns standpoint).
The biggest issue is that you end up with persistence logic spread out across all your classes. That can quickly lead to bloat, and it also embeds assumptions about your persistence technology all over your codebase. That gets messy if you need to change where or how you store your objects.
Those assumptions also make automated testing more difficult because now you have a persistence layer dependency to work around. You could inject a repository into the object to counteract some of this stuff, but then you're implementing a repository anyway. :) Better to just keep the core classes entirely peristence-ignorant if you can...
On the plus side, it's a simpler pattern for people to grasp and is a quick way to get things done on a lightweight project. If the number of classes is small it could be the quickest way to get from A to B. I still find myself building out separate repositories on small projects however, I just can't stand having persistence stuff mixed in with my business logic.
Solution 3:[3]
Cons:
- Violates Single Responsibility Principle (SRP)
- Hampers testability
- Tightly couples you business logic to your database
Pros:
- Is simple to implement
Basically, if your data model is flat and simple, and your application requirements are modest, Active Record might be a good choice; however, it starts to break down when your mapping requirements get a bit more complex. More robust ORM patterns like Data Mapper become appropriate in cases like these.
Solution 4:[4]
Pros
- simplicity
Cons
- breaks separation of concerns
- tight coupling of business logic with database
- makes testing much more difficult
This pretty much boils down to testing becoming much harder, and decreasing the time before you have to do a major refactor in your project.
At the end of the day you need to weigh your goals and concerns for the project and decide if the loss of testing/verifiability/cleaness is worth it to gain a simpler system.
If it's a simple application, you're probably fine to drop the DAL layer, and go for the simpler model. Though if you application has lots of moving parts and is of considerable complexity, I would avoid removing the DAL as you will want to be able to test and verify your code well.
Solution 5:[5]
It flies in the face of using a Data Access Layer...not that there's anything wrong with that.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | n8wrl |
| Solution 2 | |
| Solution 3 | |
| Solution 4 | elsom25 |
| Solution 5 | Steve Wellens |