1

Should I implement Dispose () in DAO standard?

I'm trying to implement a CRUD using the EF core and the DAO standard, but I don't know if I should implement and where to implement Dispose

Follow My Code:

interface IMaintanable<T> : IDisposable
    {
        void Create(T obj);
        T Retrieve(uint key);
        void Update(T obj);
        void Delete(uint key);
    }


  public class DocumentDAO : IMaintanable<Document>
        {
            public void Create(Document obj)
            {
                throw new NotImplementedException();
            }

            public void Delete(uint key)
            {
                throw new NotImplementedException();
            }

            public void Dispose()
            {
                throw new NotImplementedException();
            }

            public Document Retrieve(uint key)
            {
                throw new NotImplementedException();
            }

            public void Update(Document obj)
            {
                throw new NotImplementedException();
            }
        }
  • Possible duplicate of [When should I implement IDisposable?](https://stackoverflow.com/questions/2431488/when-should-i-implement-idisposable) – Igor Apr 12 '18 at 16:43
  • Possible duplicate of [Proper use of the IDisposable interface](https://stackoverflow.com/questions/538060/) – Igor Apr 12 '18 at 16:44

2 Answers2

1

Short answer: No.

DAOs should be simple datacontainers, contain little or no logic and certainly not contain resources. They should also not implement something like IMaintainable .

I know that all the OOP tutorials are full of examples of Business entities that end up with a Save() and a Show() method but in reality that's not how it's done.

For a basic idea, look at the Repository pattern. But that's generally considered redundant when using EF.

Also note that DAOs are not commonly used with EF - the E stands directly for the business/model/domain Entity. Using DAOs is possible but would only be considered for very large projects. Or when an existing database does not map to the business model very well.

H H
  • 263,252
  • 30
  • 330
  • 514
0

Your code, as written, doesn't need to do be disposable, because so far your class has no state.

However, once you implement all those other methods you may introduce fields, like Entity Framework containers or SQL Connections, which will need to be disposed when your class is disposed. If so, you'll want to follow the Microsoft Docs (e.g. this and this) for the correct patterns for disposing your object.

StriplingWarrior
  • 151,543
  • 27
  • 246
  • 315