CSLA 6 Naming Convention: Gateway

[TheCakeMonster]

In CSLA 6, the way we access our business objects changes. CSLA now requires dependency injection (DI) and creating, fetching and deleting objects now all have to happen via an instance of IDataPortal<T> that was created from the DI container, either directly using constructor injection, or indirectly.

For those who have not already done so, this requires changes to, or replacement of, the static factory methods we once used. Static methods are not directly compatible with DI, so we must either change these methods to pass them an instance of an object that can do our data portal operations, or we must switch to instance methods on something other than the business object - perhaps another object.

Those people who wish to create a separate class for the data portal initiation methods - the static factory methods of old - would probably benefit from a naming convention for these classes. This will ease discussions on this forum and Discord, as well as between teams. Since we are moving our factory methods it might be tempting to call this a factory object - but maybe this isn't the best approach.

There are two problems with calling these factory objects: this is a potential naming clash, but it's probably also not entirely accurate from the consumer's perspective - the user of the class we are creating. Let's discuss those two points.

Potential Naming Clash
We already have the potential for classes called object factories in the CSLA community; these form part of the Factory Implementation data access pattern, where data access code is kept outside of the business object. Avoiding confusion between the factory objects used in data access - on the server - with these new classes - usually used on the client - seems important.

Naming Accuracy
We've always called the static methods factory methods, it's just part of our lexicography. While this is true of what they do under the covers - and thus accurate from the point of view of the classes in which they are contained - it would probably appear to be slightly less accurate to our consumers. The delete operation of editable objects and the execute operation of command objects aren't really creating objects - at least not from the perspective of the external consumer.

If we create a class to do work that includes these operations it probably isn't really quite correct for the consumer to refer to the object they work with as a factory, yet it is in the consuming code that the naming convention will be seen.

Suggestion
I suggest that we call these new classes gateways. Martin Fowler's definition of a gateway is "An object that encapsulates access to an external system or resource" and that is the closest fit I can find for what these classes are doing.

https://martinfowler.com/articles/gateway-pattern.html#:~:text=An%20object%20that%20encapsulates%20access%20to%20an%20external%20system%20or%20resource

This definition isn't absolutely perfect. In our case the gateway would be providing access to something that forms a part of our system - it's not external from the perspective of the business domain. However, it may be involve a call to an external process, so it's not entirely wrong - it could be external from the perspective of the physical deployment.

If you have a CSLA Person class then the way to initiate interaction with it would be via a new class called PersonGateway. This would be a class with instance methods for creating, fetching and deleting (or executing in the context of a command object) and would receive an instance of a correctly configured IDataPortal<T> with which to do its work through constructor injection.

I'd be interested to hear other people's opinions on this naming convention. Is this usage too far from the original definition to be valid? Is the naming clash a valid concern?

[rockfordlhotka]

I agree that some standard naming is important.

I'm not entirely sure I agree with the arguments against "factory" though. Yes, within the context of CSLA there are other factories, but I think the correct design pattern name is, in fact, factory.

Another possible name would be "provider", because these objects provide instances of another type - which is what you expect from a provider.

I must confess that I'm not real keen on "gateway", because I don't think that pattern matches what we're doing here, and the general connotation of the word "gateway" implies accessing something that is somewhere else.

[TheCakeMonster]

Yeah, I know what you mean. I'm not entirely happy with gateway, although I think it might be less confusing than factory.

Could we use the word portal without it being too easily confused with the data portal that it is wrapping?

[rockfordlhotka]

I still think Factory is the right term.