ObjectContext and it's role in COM+
-
I have recently been re-evaluating the way our middle tier objects are designed and coded, including looking at their future under .Net I guess to a large extent some of my methods of coding middle tier objects have been inherited from other people's code without a complete understanding of why. A few questions have arisen regarding the use of ObjectContext to create objects and so forth, especially in regard to COM+, but also wondering how things will change moving to .Net 1) All middle tier object instatiating (BLL creates DAL object, or BLL creates different BLL object) uses ObjectContext.CreateInstance. As I understand it, this will ensure the created object executes within the activity, the transaction (if there is one) and the security context of the client object. Assuming my object is non transactional and I am not using security roles or such, do I still need to create objects in this manner? 2) Looking at the data access "helper" methods I see that someone has decided to ObjectContext.CreateInstance ADO objects. Is this wise? Are they threaded in such a way as to make them safe to run in an MTS activity? 3) All the documentation on ObjectContext talks about MTS, but there is no mention of it in the COM+ docs. Is there a good reason for this? What happened to ObjectContext in COM+? 4) In .Net it seems that my BLL and DAL objects would live in assemblies placed inteh ASP.Net Application's /bin/ directory and no longer require registering with COM+. Thank god I say, but are these assemblies still going to run under the supervision of COM+? And what happens to ObjectContexts under .Net? Even if I could be pointed in the direction of some useful reading material that would be swell.
-
I have recently been re-evaluating the way our middle tier objects are designed and coded, including looking at their future under .Net I guess to a large extent some of my methods of coding middle tier objects have been inherited from other people's code without a complete understanding of why. A few questions have arisen regarding the use of ObjectContext to create objects and so forth, especially in regard to COM+, but also wondering how things will change moving to .Net 1) All middle tier object instatiating (BLL creates DAL object, or BLL creates different BLL object) uses ObjectContext.CreateInstance. As I understand it, this will ensure the created object executes within the activity, the transaction (if there is one) and the security context of the client object. Assuming my object is non transactional and I am not using security roles or such, do I still need to create objects in this manner? 2) Looking at the data access "helper" methods I see that someone has decided to ObjectContext.CreateInstance ADO objects. Is this wise? Are they threaded in such a way as to make them safe to run in an MTS activity? 3) All the documentation on ObjectContext talks about MTS, but there is no mention of it in the COM+ docs. Is there a good reason for this? What happened to ObjectContext in COM+? 4) In .Net it seems that my BLL and DAL objects would live in assemblies placed inteh ASP.Net Application's /bin/ directory and no longer require registering with COM+. Thank god I say, but are these assemblies still going to run under the supervision of COM+? And what happens to ObjectContexts under .Net? Even if I could be pointed in the direction of some useful reading material that would be swell.
JBoy wrote: 4) In .Net it seems that my BLL and DAL objects would live in assemblies placed inteh ASP.Net Application's /bin/ directory and no longer require registering with COM+. Thank god I say, but are these assemblies still going to run under the supervision of COM+? And what happens to ObjectContexts under .Net? From what I've read any COM+ assemblies have to be registered in the GAC, and then referenced by managed code in the usual way. The assembly attributes specify how it is to be installed into COM+ without you doing much. However, if it needs to be referenced by unmanaged code then you have to do a little more (don't remember off the top of my head, sorry). As a result, I don't think you can do a regular xcopy deploy (which is what I assume you were meaning). That's about the extent of my COM+ knowledge at the moment, looking to tackle it a bit more of the next few days!
-
JBoy wrote: 4) In .Net it seems that my BLL and DAL objects would live in assemblies placed inteh ASP.Net Application's /bin/ directory and no longer require registering with COM+. Thank god I say, but are these assemblies still going to run under the supervision of COM+? And what happens to ObjectContexts under .Net? From what I've read any COM+ assemblies have to be registered in the GAC, and then referenced by managed code in the usual way. The assembly attributes specify how it is to be installed into COM+ without you doing much. However, if it needs to be referenced by unmanaged code then you have to do a little more (don't remember off the top of my head, sorry). As a result, I don't think you can do a regular xcopy deploy (which is what I assume you were meaning). That's about the extent of my COM+ knowledge at the moment, looking to tackle it a bit more of the next few days!
Most of those questions were regarding traditional COM+ dlls. However this last question was really concerning pure .Net assemblies. Let me rephrase: 4) Rewriting my BLL and DAL objects in .Net, it seems that they would live in assemblies placed in the ASP.Net Application's /bin/ directory and no longer require registering with COM+. Thank god I say, but are these assemblies still going to run under the supervision of COM+ (IS there a COM+ in .Net)? And what happens to ObjectContexts under .Net? Since part of the role of Contexts was to ensure that MTS could manage security roles, resource management and the like; I am guessing that these benefits are inherant with any managed code. Clearly I need to learn more about what happened to COM+ services with the advent of .Net
-
Most of those questions were regarding traditional COM+ dlls. However this last question was really concerning pure .Net assemblies. Let me rephrase: 4) Rewriting my BLL and DAL objects in .Net, it seems that they would live in assemblies placed in the ASP.Net Application's /bin/ directory and no longer require registering with COM+. Thank god I say, but are these assemblies still going to run under the supervision of COM+ (IS there a COM+ in .Net)? And what happens to ObjectContexts under .Net? Since part of the role of Contexts was to ensure that MTS could manage security roles, resource management and the like; I am guessing that these benefits are inherant with any managed code. Clearly I need to learn more about what happened to COM+ services with the advent of .Net
As far as I understand it the assemblies are added to COM+ at the time they are requested by a client (provided you specify all the necessary attributes). However, the only examples I've seen require that you register the assembly in the GAC, which requires you to run gacutil /i and thus have access to the server's command line. Now, your hosting Company may allow this, and they may be more willing to do it since its very straightforward and is unlikely to break support for anything else already in there. I'm not too geared up on ObjectContexts (since I've only ever tried to use COM+ with .NET, and never really got into it with traditional VB6/ATL), take a look at the ServicedComponent class and it'll probably give you more info about context. I'm not too sure whether COM+ security settings over-ride those set by the assembly attributes, or vice versa.