CSLA .NET

In the CSLA; the business objects have the responsibility to access the database. I would like to have a separate access layer, so I could change of database without modifying the BO. I could implement a simple data layer, an object with method who’ll get object to save, update, etc. as parameters, like MyDataAccesObjectLayer.Save(aCustomer).

 

But how that could work? In order to save aCustomer, MyDataAccesObjectLayer should know the private property of aCustomer? OR THE DataLayer object could in a propriety of the object to save; so it would have access to its members?

 

Do you know any example or framework that does that?

 

Cordially

 

Richard

---

Richard

Yes you can do this, but it discards the use of  "Mobile Objects" and the goodies of the proxies that csla data portal provides.
We do this in a number of applications that need to support legacy COM+ etc server architectures ( although gradually migrating to remoting and System Transactions instead) .

You can bypass csla DataPortal simply by overridiing Save() in BusinessBase etc and pointing your updates to your own dataportal service (tcp preferred).
Rocky does not go into the details of a tcp remoting service - but I can tell you that it really rocks compared with using Soap and IIS etc.

jimbo

I should add that in these scenarios we are using simple old fashioned DTO's and parameterized calls that do not have any reference to the BO's on the server.

Thanks for the answer. My idea was not to bypass the data portal. The BO would have their dataPortal methods, but instead of implementing them, they would use an access data layer.

 

By example, in a BO, DataPotal_Fetch(), instead of doing some SQL, would call the data access layer. Like this, we would keep the benefits of the CSLA framework.

---

Richard

csla does not dictate the data access or provider that is to be used ( although it is ms sql centric by default) . You can use whatever data access provider (MySql, Oracle, XML, CSV, Excell, Access etc ) you wish to code for in each of  your DataPortal_Fetch, Insert, Update etc methods. Clearly you would also have to replace  datareaders etc as appropriate for loading datarows or otherwise provide suitable adaptors for the type of rowsets that you get..
If you wanted to be able to use alternate or switchable sources than perhaps it would require switchable cases in each method dependent on the provider. This suggestion of course is not ideal as it would blow out the code base in the objects and any future provider changes would similarly require rebuilding.
How to have a universal persistence layer without provider customisation is beyond me at this point

Here are a couple relevant articles:

http://www.lhotka.net/Article.aspx?area=4&id=b99dfec2-c079-4b85-98df-ea3582c28386

 

http://www.lhotka.net/Article.aspx?area=4&id=2e6468d6-9a02-4f0e-a31c-a7eecc268e1b

---

Rocky

Another alternative you might want to consider involves the Separated Interface pattern(Fowler).  You could create an explicit interface for each BO and place them in a separate assembly.  Each BO would implement its own explicit interface and pass that to the DAL.  The key is to use explicit interfaces and not implicit interfaces.  Explicit interfaces allow you to access private properties when you cast to the interface.  This allows you to load and save objects from the DAL.  Any code that does not have a reference to the explicit interfaces assembly will not have access to the private properties.  This allows you to hide private properties from the presentation layer while exposing them to the DAL.

Thanks for the links, Rocky.

First time I heard of  Separated Interface pattern ;) . And I do not know the difference between explicit and implicit interfaces. I’ll invoke my all knowing god, Google!

Edit: well, I found things on explicit interfaces, like:

The class member IControl.Paint is only available through the IControl interface, and ISurface.Paint is only available through ISurface. Both method implementations are separate, and neither is available directly on the class. For example:

SampleClass obj = new SampleClass();
//obj.Paint();  // Compiler error.

IControl c = (IControl)obj;
c.Paint();  // Calls IControl.Paint on SampleClass.

ISurface s = (ISurface)obj;
s.Paint(); // Calls ISurface.Paint on SampleClass.

RichardETVS:

So the idea is to implement a public interface to expose private properties, and as this public interface is not available in the UI, the private properties stay hidden for the UI developer? That seems really interesting.

Not quite; you want an internal interface, not a public interface.  If you make the interface public, then the explicit implementation of the interface will be visable as well.  If the interface is internal and you implement it explicity, then only classes internal to the assembly can see the private bits, but your UI code will still not be able to see it.

ajj3085:

Not quite; you want an internal interface, not a public interface.

Well, I do not get it, then. When I read “You could create an explicit interface for each BO and place them in a separate assembly”, it seems to me that I can’t use internal scope.

---

Richard

That's correct, I'm not sure where malloc was going with his idea of seperate assemblies.. but if you put the interfaces in a seperate assembly, that assembly needs to be seen by any other assembly that uses your BO.  That ends up defeating what you want to do, which is keeping the implementation of the interface on your BO private.

But f the interface assembly is referenced only the BO assembly and the DAL assembly, and the implementation of the interface are explicit, it seems to me that the encapsulation is preserved, because only the DAL will have access to the private fields of the BO.

---

Richard

I'm sure that anything which references your BO assembly will also have to reference the interface assembly, and thus could use that interface to modify the property values bypassing the normal Csla properties (i.e., the rules wouldn't run, etc.). 

The only way to truely prevent this is to keep the interfaces internal to the BO assembly.  You would then need some kind of mapper which takes the DAL object and sets properties via the interface.

Attached is a sample application which illustrates the problem.

It works in VB.NET but it appears that is doesn’t work quite as well in C#.  I just tested it in C# and it appears the presentation layer needs to have a reference to the separated interfaces assembly.  This is not the case for VB.NET.  The presentation layer doesn’t need to have a reference to the separated interfaces assembly in VB.NET.  I am not sure why it works in VB.NET and not in C#.  Anyway, even if the presentation layer had a reference to the separated interfaces, it would not be able to access the hidden properties of an object unless it was casted to its separated interface.  However, this does not work as well.

You could keep the interface internal to the BO assembly and use the
InternalsVisibleTo attribute to expose it to the data layer.