ServiceDependency, CreateNew, InjectionConstructor

Topics: CAB & Smart Client Software Factory
Dec 29, 2005 at 1:25 PM
originally posted by: NandanNaik

Hello,

Could someone please clarify what the significance of these terms is:

ServiceDependency: Used when we need to obtain a reference to an _existing_ service or workitem. (If service dependency is also used to obtain references to workitems also, why is it called _Service_ dependency?)

Createnew: Used when we need a _new_ object of some type that is decorated by this attribute.

InjectionConstructor: The constructor called (among a set of constructors available for a certain object) when the ObjectBuilder needs to instantiate a new object of some type.

Are these definitions correct? Could someone please confirm / correct me.

Thanks.

-Nandan
Dec 29, 2005 at 1:29 PM
originally posted by: BradWilsonMSFT

Yes, all of that is true.

You can think of services vs. items in this way. Services are found by type only, and items are found either by name, or by type and name. (The fact that services climb the tree isn't important for the moment.)

Within this description, you can see why we registered WorkItem as a service: finding it by type should be sufficient. There are also further interesting complications, like the fact that WorkItems are both participants in the container system (of their parent) and the container themselves (for their own items). The name, if you had one, would be the WorkItem's name in the context of its parent, not itself.
Dec 29, 2005 at 1:51 PM
originally posted by: NandanNaik

Brad, thanks for the reply.

So if I understand you correctly, <ServiceDependency()> allows us to find workitems by type. So, as far as the attribute <ServiceDependency()> is concerned, the object builder treats finding references to Workitems and Services alike.

But, if we were to find references to the workitems by "name", how could we do that?

(Also, isnt it a little bit of a stretch to obtain references to the Workitem as well through the ServiceDependency attribute? A misnomer in some sense.)

Appreciate your reply.

-Nandan
Dec 29, 2005 at 3:15 PM
originally posted by: BradWilsonMSFT

It's not really a misnomer, because "service" is probably used in a looser context here than most people use it.

When you do a ServiceDependency for the type WorkItem, you will find the WorkItem in which YOU are contained. When you do a ComponentDependency for a named WorkItem, you will find the CHILD WorkItems in the WorkItem in which YOU are contained. It'll work just fine, if that's what you're after.
Dec 30, 2005 at 2:41 PM
originally posted by: dfoderick

"if we were to find references to the workitems by "name", how could we do that?"

Are you trying to get a reference to something in the Items collection? Use the indexer with a string parameter.

WorkItem.Items"PutItemNameHere"
Feb 2, 2006 at 5:46 AM
originally posted by: pariampampam

IMHO, the term Service relates to the "Service Layer" of an application. Thus referring to the WorkItem as a Service (using ServiceDependecy attribute) seems a misnamer to me, too.

The fact that up until now no one of our team could tell for sure what the ServiceDependency is for and what it ain't also does not speak in favor of its naming.
Feb 3, 2006 at 1:48 PM
originally posted by: RayHeath

So I am intrigued by the attributes CreateNew and ServiceDependency. If I have two different views that would benefit from using the same controller, can I do something like this?

Inside SmartPartA (which gets loaded first)
CreateNew
public SessonController Controller
{
set { controller = value; }
}

Inside SmartPartB (which gets loaded second)
ServiceDependency
public SessonController Controller
{
set { controller = value; }
}

Well, apparently not (at least with CAB out of the box) . . .
Feb 4, 2006 at 2:10 PM
originally posted by: ChrisHolmes

I think the reason that doesn't work is because with the CreateNew attribute you are just creating a new object (in this case, a controller) and injecting it into your SmartPart. However, that Controller is not being registered with any Service as an item that can be referenced via the ServiceDependency attribute.