ObjectContext

  • Thread starter Thread starter shapper
  • Start date Start date
S

shapper

Hello,

I have the following:

using System;
using System.Data.Objects;

public class MyAppContext : ObjectContext, IUnitOfWork {

public void Commit() {
SaveChanges();
} // Commit

public void Rollback() {
Dispose();
} // Rollback
}

}

I get an error on MyAppContext:
'System.Data.Objects.ObjectContext' does not contain a constructor
that takes '0' arguments

What am I missing?

My IUnitOfWork is as follows:

public interface IUnitOfWork {
void Commit();
void Rollback();
} // IUnitOfWork

Thank You,
Miguel
 
shapper said:
Hello,

I have the following:

using System;
using System.Data.Objects;

public class MyAppContext : ObjectContext, IUnitOfWork {

public void Commit() {
SaveChanges();
} // Commit

public void Rollback() {
Dispose();
} // Rollback
}

}

I get an error on MyAppContext:
'System.Data.Objects.ObjectContext' does not contain a constructor
that takes '0' arguments

What am I missing?

My IUnitOfWork is as follows:

public interface IUnitOfWork {
void Commit();
void Rollback();
} // IUnitOfWork

Thank You,
Miguel
Click to expand...

Well, if you look at your class ObjectContext, which you did not
include, you will see it has no constructors that take no arguments.
Just add public ObjectContext () {} to that class.
 
Hello,

I have the following:

using System;
using System.Data.Objects;

public class MyAppContext : ObjectContext, IUnitOfWork {

public void Commit() {
SaveChanges();
} // Commit

public void Rollback() {
Dispose();
} // Rollback
}

}

I get an error on MyAppContext:
'System.Data.Objects.ObjectContext' does not contain a constructor
that takes '0' arguments

What am I missing?
Click to expand...

You are missing an explicit call to an ObjectContext constructor, passing
the required arguments to it.

Because MyAppContext inherits ObjectContext, it has to provide a valid way
to initialize the base class, ObjectContext. Without an explicit call,
the only way to do that is for the default, parameterless constructor to
be called. But if none exists in ObjectContext (and none does), it's not
possible to initialize the base class that way. Thus, you are required to
provide an explicit way to initialize it.

One possibility is for you to duplicate any constructors that you would
have used were you using ObjectContext directly. For example:

public class MyAppContext : ObjectContext, IUnitOfWork
{
public MyAppContext(EntityConnection ec) : base(ec) { }
public MyAppContext(string str) : base(str) { }
public MyAppContext(EntityConnection ec, string str) : base(ec, str) {
}
public MyAppContext(string str1, string str2) : base(str1, str2) { }

public void Commit() {
SaveChanges();
} // Commit

public void Rollback() {
Dispose();
} // Rollback
}

Another possibility is for you to provide arguments to the base
constructor from values found elsewhere (e.g. returned from a static
property or method somewhere, or retrieved from some other object, either
available statically or passed to the constructor, that sort of thing).

Pete
 
You are missing an explicit call to an ObjectContext constructor, passing 
the required arguments to it.

Because MyAppContext inherits ObjectContext, it has to provide a valid way  
to initialize the base class, ObjectContext.  Without an explicit call, 
the only way to do that is for the default, parameterless constructor to  
be called.  But if none exists in ObjectContext (and none does), it's not  
possible to initialize the base class that way.  Thus, you are requiredto  
provide an explicit way to initialize it.

One possibility is for you to duplicate any constructors that you would  
have used were you using ObjectContext directly.  For example:

   public class MyAppContext : ObjectContext, IUnitOfWork
   {
     public MyAppContext(EntityConnection ec) : base(ec) { }
     public MyAppContext(string str) : base(str) { }
     public MyAppContext(EntityConnection ec, string str) : base(ec, str) {  }

     public MyAppContext(string str1, string str2) : base(str1, str2) { }

     public void Commit() {
       SaveChanges();
     } // Commit

     public void Rollback() {
       Dispose();
     } // Rollback
   }

Another possibility is for you to provide arguments to the base  
constructor from values found elsewhere (e.g. returned from a static  
property or method somewhere, or retrieved from some other object, either 
available statically or passed to the constructor, that sort of thing).

Pete
Click to expand...

Thank You. It worked.

Just one question:

I am implementing the pattern IUnitOfWork and named the interface
IUnitOfWork.

Should I name it something else like for example ISession ...
.... Since Unit of Work pattern when used it seems like a Session being
opened and the changes are submitted on commit.

Just wondering how people usually call it.

Thanks,
Miguel
 
[...]
I am implementing the pattern IUnitOfWork and named the interface
IUnitOfWork.

Should I name it something else like for example ISession ...
... Since Unit of Work pattern when used it seems like a Session being
opened and the changes are submitted on commit.

Just wondering how people usually call it.
Click to expand...

They use all sorts of names. :) Many people, such as myself, have not
even heard of the particular name "unit of work" design pattern, even
though we've used that sort of design pattern in our own code.

I would say that if you are really intending to follow the particular
documented "unit of work" design pattern, you might as well use that as
the name. Just because the unit of work happens to be a session, that
doesn't mean that's what the interface ought to be called.

Of course, that assumes that the IUnitOfWork interface really is abstract
enough to not show the "session-ness" of it. It appears that's the case,
but only you can say for sure. That said, if your "MyAppContext" class
really does represent a session of some sort, it seems to me that _that_
class could be better named, so as to reflect the session nature of the
class.

Pete
 
Back
Top