If you ever think of this, I appreciate you, you are in the right direction. You know, there are few questions that has no answer and this is one of that kind. Personally, one of the most compelling exercises in software engineering is exploration, just like in any other engineering field. The rule is that there is no rule to use the Design patterns. Your experience (success more than failures) will tell you when to use them purely, when to adapt them or when not to use them at all.
As a communication medium, Design patterns are awesome. The more we build software with them in mind, the better off we’ll be as a community. They can help us elegantly construct solutions which can be readily discussed with peers.
Though the Repository Pattern is one of the most popular patterns to create an enterprise level application. It adds another layer of abstraction which adds a certain level of complexity making it an overkill for small applications.
On the other hand, DataManager can be used where Repository Pattern becomes complex.
A pattern is an idea of how to solve a problem of some class. An anti-pattern is an idea of how not to solve it because implementing that idea would result in bad design.
A “pattern” would be to use a function for code reuse, an “anti-pattern” would be to use copy-paste for the same. Both solve the same problem, but using a function usually leads to more readable and maintainable code then copy-paste.
In other words, as opposed to design patterns which are common approaches to common problems which have been formalized, and are generally considered a good development practice, anti-patterns are the opposite and are undesirable.
Despite IDisposable having only a single method named Dispose to implement, it is commonly implemented incorrectly. After reading this blog post it should be clear how and when to implement IDisposable, as well as how to ensure that resources are properly disposed when bad things happen (also knows as exceptions).