factory methods vs Dataportal methods

[Chicagoan2016]

Take the example of ProjectExistsCommand object in Project Tracker. In ProjectEdit.cs we are calling ' DataPortal.Execute(cmd);'

What if we have a static method in Command object and then call DataPortal.Execute from the static method? Which way is better?

Regards

[rockfordlhotka]

"Better" is such a relative term 😄

I've always liked the static factory method approach because it provides an intuitive, consistent, and abstract API for UI developers as they interact with the business layer.

However, static methods are very poor from an automated testing/mocking/DI perspective. So if you are less into intuitive APIs and more into using mocking and DI concepts then they aren't such a good idea.

[Chicagoan2016]

Thank you Rocky, does it mean that any object stereotype can be called outside that object (e.g UI) by using DataPortal.XYZ method?

Regards

[ajj7060]

@Chicagoan2016 I would recommend not using DataPortal.XYZ<T> calls outside of the business layer anywhere. The data portal should be an implementation detail that your UI layer doesn't really know about.

In your business layer though, I don't think you need to avoid calling DataPortal.XYZ<T>. An example might be if you want to do dependency injection, so you might have an IProductFactory, and a ProductFactory which implements the interface by calling DataPortal.Fetch<Product>. But if you're not doing something like that, you're probably better sticking to the static factory methods being part of the Product class, as that will be familiar to other Csla devs (if you happen to find one to hire).

[Chicagoan2016]

Thanks @ajj7060 for the helpful post, the last part "as that will be familiar to other Csla devs (if you happen to find one to hire)." made me smile : )

Regards