Injecting Commerce Server 2007 Catalog Context demonstrated a simple technique for injecting catalog context and for writing catalog code that can be used on both the web tier and the service tier. The same technique can be used to get a Commerce Server 2007 profile context.
First, we define the factory interface for creating a profile context:
1 using Microsoft.CommerceServer.Runtime.Profiles;
2
3 namespace MyCommerceApplication
4 {
5
6 /// <summary>
7 /// Factory used to create catalog context objects for accessing the Commerce Server profile
8 /// subsystem.
9 /// </summary>
10 public interface IProfileContextFactory
11 {
12 #region Methods
13
14 /// <summary>
15 /// Creates a profile context.
16 /// </summary>
17 /// <returns>A <see cref="ProfileContext"/> object.</returns>
18 ProfileContext CreateProfileContext();
19
20 #endregion // Methods
21 }
22
23 }
Second, we implement the factory interface using CommerceContext.Current.ProfileSystem for the web tier:
1 using Microsoft.CommerceServer.Runtime;
2 using Microsoft.CommerceServer.Runtime.Profiles;
3
4 namespace MyCommerceApplication
5 {
6
7 /// <summary>
8 /// A profile context factory that can be used on the web tier.
9 /// </summary>
10 public sealed class WebTierProfileContextFactory : IProfileContextFactory
11 {
12 #region IProfileContextFactory Members
13
14 /// <summary>
15 /// Gets the profile system for the current commerce context.
16 /// </summary>
17 /// <returns>The current commerce context's <see cref="ProfileContext"/> object.</returns>
18 public ProfileContext CreateProfileContext()
19 {
20 return CommerceContext.Current.ProfileSystem;
21 }
22
23 #endregion // IProfileContextFactory Members
24 }
25
26 }
Third, we implement the factory interface for the service tier. This is a bit more involved than creating a catalog context on the service tier was, as there isn't a "ProfileSiteAgent" class or a "ProfileContext.Create" method that does the heavy lifting for us. We need to use CommerceResourceCollection to load the connection strings for the profile subsystem, create a DebugContext, and pass everything into the ProfileContext constructor:
1 using Microsoft.CommerceServer.Runtime.Configuration;
2 using Microsoft.CommerceServer.Runtime.Diagnostics;
3 using Microsoft.CommerceServer.Runtime.Profiles;
4
5 namespace MyCommerceApplication
6 {
7
8 /// <summary>
9 /// A profile context factory that can be used on the service tier.
10 /// </summary>
11 public class ServiceTierProfileContextFactory : IProfileContextFactory
12 {
13 #region IProfileContextFactory Members
14
15 /// <summary>
16 /// Creates a new profile context.
17 /// </summary>
18 /// <returns>A new <see cref="ProfileContext"/> object.</returns>
19 public ProfileContext CreateProfileContext()
20 {
21 CommerceResourceCollection resources;
22 CommerceResource resource;
23 string profileServiceConnectionString;
24 string commerceProviderConnectionString;
25 string bizDataStoreConnectionString;
26 DebugContext debugContext;
27 ProfileContext profileContext;
28
29 // NOTE: This is a trivial implementation of IProfileContextFactory. A more realistic
30 // implementation would inject the resources, inject the debug context, have error
31 // handling, caching, etc.
32
33 resources = new CommerceResourceCollection("MySite"); // TODO: Read the site name from configuration.
34 resource = resources["Biz Data Service"];
35 profileServiceConnectionString = (string)resource["s_ProfileServiceConnectionString"];
36 commerceProviderConnectionString = (string)resource["s_CommerceProviderConnectionString"];
37 bizDataStoreConnectionString = (string)resource["s_BizDataStoreConnectionString"];
38 debugContext = new NoOperationDebugContext(DebugMode.Production);
39 profileContext = new ProfileContext(profileServiceConnectionString, commerceProviderConnectionString, bizDataStoreConnectionString, debugContext);
40 return profileContext;
41 }
42
43 #endregion // IProfileContextFactory Members
44 }
45
46 }
(Note the disclaimer. This is a trivial implementation. If you get your service interfaces right and have a dependency injection strategy, though, you can go a long way with trivial implementations. :)
The rest of the steps are the same as in the original post. We
- configure our application's dependency injection framework to map the factory interface to the factory implementation appropriate to the tier;
- write code that depends on the factory to create profile contexts, advertising the dependency using DependencyAttribute;
- creating a mock implementation of the factory for testing;
That's it. The code written against the factory interface can be used in both the web tier and the service tier without modification and without needing to know where it lives in the solution architecture.
Cheers,
Colin