ObjectFactory

ObjectFactory

Old forum URL: forums.lhotka.net/forums/t/6326.aspx

rfcdejong posted on Wednesday, February 04, 2009

Ok, it really has it's limits.

The business object has dirty flags and is the only one knowing what has to be updated.
The ObjectFactory breaks the encapsulation and single responsibility quite a bit, but offers more flexibility. And it gives a better separation between the business layer and data access layer. Performance is very important but on the other hand it shouldn't get too complex!

It's more work for sure, but most of it works. And in the new 3.6.1 version Rocky implemented the LoadProperty method in the ObjectFactory.

But until now i bumped into several limitations:

1) Lazy loading
Using lazy loading with FieldManager.FieldExists(..) works fine until u want to let the root objectfactory persist the business object.
Problem: The objectfactory has no access to the Fieldmanager and so it'll trigger an LoadProperty.

2) DeletedList
A child as BLB contains deleted childs, an properted property in the BLB. Normally the DataPortal does a UpdateChild resulting in the Child_Update method being executed. Each item in the DeletedList is then being deleted, before the DeletedList is cleared.
Problem: The objectfactory has no access to the DeletedList, so it can't delete those items.


Can those 2 points be solved somehow?
Exposing the FieldManager to the ObjectFactory is not really nice..

RockfordLhotka replied on Wednesday, February 04, 2009

I'll add these to the wish list.

As I've said in other threads, the primary purpose behind ObjectFactory is/was to lay the foundation to support a future version of ADO.NET EF.

At the same time, I also figured people would use it for various other types of DAL as well. And I did as little as possible around that, because it wasn't (and still isn't) clear to me what would be the best overall approach to building such a DAL.

Certainly this direct approach of having the factory methods reach into the guts of a business object and twist them around is an obvious answer - but I really am not so sure it is elegant or even wise. The coupling between the business and factory objects, and the blatant disregard for encapsulation boundaries really bothers me.

At the same time, the ObjectFactory base class has already started down this road, and so it may be that I just keep adding more protected methods to this class to enable tighter coupling and so forth.

What I _hope_ is that someone thinks of a solution that has better decoupling and protects encapsulation more effectively. I haven't had time to put a lot of thought into that myself, but I think the possibility exists.

And if that happens, I can see adding another base class like ObjectFactory, but one that exposes protected methods to enable that more elegant scenario.

I'm not trying to criticize what you are doing! I'm just trying to challenge everyone to think about the consequences of this approach, and to consider that there might be other approaches.

For example, I am hopeful that a future EF will use a lambda-based construct to get/set business object field values. In other words, EF will define a delegate signature for get and for set, and CSLA will be able to give EF a lambda that fulfills that requirement. Behind the scenes, the lambda will call ReadPorperty() and LoadProperty(), but to EF it will appear as a standardized get or set method.

I don't yet know how they intend on letting something like CSLA control the creation of specific object instances - or if that's even in the cards. But I imagine a similar delegate/lambda scheme can work for that as well.

But on the whole, this idea of an external DAL is a mess - because it breaks encapsulation by definition, and because it clearly leads (in any current incarnation I've seen) to really tight coupling beween the business and factory objects.

And my worry is that 6 to 18 months from now we'll all discover that the end result isn't great.

rfcdejong replied on Wednesday, February 04, 2009

The main reason i'm using the objectfactory is:

1) In the business and frontend assembly's there is totally no references needed to any assembly's required by the data access layer.

2) Our lists can have multiple objects comming from differend data sources, not only the customer database but also an webservice. The business object has a property so the objectfactory can update the correct database or webservice. VETRO? :)
How will it work when i the dataportal_xyz methods..

Anyway i hope u are wrong that we'll all discover that the endresult won't be great.


Maybe i can still dump the whole idea of using the objectfactory, it isn't too late yet... i'm still in a pre-fase for building an framework.

nermin replied on Wednesday, February 04, 2009

I might be wrong, but it appears to me that you can accomplish 1) and 2) without no need for Object Factory.  Check Frank’s post on StructureMap and Csla:

 

http://maonet.wordpress.com/2008/08/08/using-structuremap-to-mock-dataaccess-in-csla-bo/

 

One important thing to note is that in Frank’s code example “ObjectFactory” is a StructureMap class.  It happens to have a same name as Csla ObjectFactory, but serves a different purpose.

 

I truly believe that using StructureMap(Unity or Windsor, or some other IoC tool) to separate out dependencies is a better/simpler way to do this, and for now lets leave ObjectFactory as a placeholder for future EF integration.

 

Nermin

 

From: rfcdejong [mailto:cslanet@lhotka.net]
Sent: Wednesday, February 04, 2009 10:04 AM
To: Nermin Dibek
Subject: Re: [CSLA .NET] ObjectFactory

 

The main reason i'm using the objectfactory is:

1) In the business and frontend assembly's there is totally no references needed to any assembly's required by the data access layer.

2) Our lists can have multiple objects comming from differend data sources, not only the customer database but also an webservice. The business object has a property so the objectfactory can update the correct database or webservice. VETRO? :)
How will it work when i the dataportal_xyz methods..

Anyway i hope u are wrong that we'll all discover that the endresult won't be great.


Maybe i can still dump the whole idea of using the objectfactory, it isn't too late yet... i'm still in a pre-fase for building an framework.



RockfordLhotka replied on Wednesday, February 04, 2009

Nermin is correct, it is absolutely possible to build a nice DAL for use directly from the DataPortal_XYZ methods. I prototyped this a long time ago in the DeepData sample app, and Frank applied some really nice patterns to the overall concept.

 

One key thing to note about both DeepData and Frank’s post, is the use of a DTO to transport data between the business object and DAL. This is the primary mechanism available for decoupling the two objects, and it can help preserve encapsulation.

 

The use of DTOs incurs overhead and requires more code, but the end result is good from an architectural perspective.

 

Rocky

 

RockfordLhotka replied on Wednesday, February 04, 2009

I’m not trying to discourage you from using the object factory concept – don’t get me wrong.

 

I’m just saying that it is a new concept, and so my implementation thus far has been as conservative as possible, because I don’t know yet what is a good or bad practice.

 

I totally understand the desire to have an external DAL assembly!

 

And most of the problems I listed in my previous post are universal to having an external DAL. That concept, in general, forces you to break encapsulation. And I have yet to see a solution that didn’t incur a lot of tight coupling.

 

Rocky

 

From: rfcdejong [mailto:cslanet@lhotka.net]
Sent: Wednesday, February 04, 2009 10:03 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] ObjectFactory

 

The main reason i'm using the objectfactory is:

1) In the business and frontend assembly's there is totally no references needed to any assembly's required by the data access layer.

2) Our lists can have multiple objects comming from differend data sources, not only the customer database but also an webservice. The business object has a property so the objectfactory can update the correct database or webservice. VETRO? :)
How will it work when i the dataportal_xyz methods..

Anyway i hope u are wrong that we'll all discover that the endresult won't be great.


Maybe i can still dump the whole idea of using the objectfactory, it isn't too late yet... i'm still in a pre-fase for building an framework.



FrankM replied on Wednesday, February 04, 2009

1) Exposing FieldManager to be public.
2) I don't think using ObjectFactory for BusinessList is a good idea, it only makes things more complicated. Just leave those Child_XYZ methods still in ChildBO.

To solve the problem completely, move relationship to ORM, then you can retire FieldManger from BO.

RockfordLhotka replied on Wednesday, February 04, 2009

As I’ve said in a couple other threads, the field manager exists to avoid the requirement for reflection during serialization. Field manager doesn’t exist for data access or data factories or any of these concepts. It exists so it is possible to serialize an object graph without reflection (for Silverlight).

 

Rocky

 

 

From: FrankM [mailto:cslanet@lhotka.net]
Sent: Wednesday, February 04, 2009 10:02 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] ObjectFactory

 

1) Exposing FieldManager to be public.
2) I don't think using ObjectFactory for BusinessList is a good idea, it only makes things more complicated. Just leave those Child_XYZ methods still in ChildBO.

To solve the problem completely, move relationship to ORM, then you can retire FieldManger from BO.


Copyright (c) Marimer LLC