ObjectContext

[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

 

[Family Tree Mike]

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

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.

 

[Family Tree Mike]

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.

Sorry, missed the namespace in question. You are going to have to
create a constructor in MyAppContext that calls one of the other
constructors in ObjectContext shown here:
http://msdn.microsoft.com/en-us/library/system.data.objects.objectcontext.objectcontext.aspx.

 

[Peter Duniho]

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?

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

 

[shapper]

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

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

 

[Peter Duniho]

[...]
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.

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