Greetings all,

Having read some of the threads in the Architecture thread, I have the following questions

1- Frans explains in one of the threads that we should NOT confuse Entities with BusinessObjects. I see a BO (in its simplest form) as an entity with business logic attached to it. LLBL has made validation of fields and the entity itself quite easy so that we do NOT have to extend the generated entities. Is this state of thinking correct or do I have any blind spots here?

2- I am a big fan of self-servicing entities because they closely resemble BusinessObjects

a Business Object is defined by BEHAVIOURE, NOT by DATA

and frankly because they are so conveniant. What got me worried is that FRANS discourged using self-servicing entities when remoting is an issue. My take on a BL tier is that it can either be deployed in the same AppDomain of the UI or on a seperate AppDomain (hosted in an application server) without having to change any implementation code (probably change the LoadPath of BL from the UI through an entry in the AppConfig as in the CSLA framework) Is it possible have similar deployment flexibility with LLBL's self-service entities and Why is self-service NOT suitable for remoting senarios?

3- Reading LLBL's documentation, I could NOT figure out senarios that we would use UnitOfWork. Could anyone give examples of such cases?

Omar

omar wrote:

2- I am a big fan of self-servicing entities because they closely resemble BusinessObjects

a Business Object is defined by BEHAVIOURE, NOT by DATA

and frankly because they are so conveniant. What got me worried is that FRANS discourged using self-servicing entities when remoting is an issue. My take on a BL tier is that it can either be deployed in the same AppDomain of the UI or on a seperate AppDomain (hosted in an application server) without having to change any implementation code (probably change the LoadPath of BL from the UI through an entry in the AppConfig as in the CSLA framework) Is it possible have similar deployment flexibility with LLBL's self-service entities and Why is self-service NOT suitable for remoting senarios?

Mainly because the Self-Servicing entities contain persistence logic (i.e. "Save") that can't be used in a remoting scenario; the database isn't available to the client-activated object, thus can't be saved against.

For Adapter the persistence logic is contained in the adapter itself; you pass an entity to the Adapter's SaveEntity() method and the entity is saved. In the remoting scenario the adapter is located in the BL/Server tier, and the entity can be passed anywhere necessary. The only way the entity can be persisted is to pass it back to the server/BL tier.

Jeff...

omar wrote:

Having read some of the threads in the Architecture thread, I have the following questions

1- Frans explains in one of the threads that we should NOT confuse Entities with BusinessObjects. I see a BO (in its simplest form) as an entity with business logic attached to it. LLBL has made validation of fields and the entity itself quite easy so that we do NOT have to extend the generated entities. Is this state of thinking correct or do I have any blind spots here?

You have to categorize the various levels of business logic. I think there are 3 categories: 1) BL which focusses on a single field (OrderID > 0) 2) BL which focusses on a set of fields (OrderDate <= ShippingDate) 3) BL which focusses on the state(s) of related entities in combination with the state of the current entity. (Current customer is a gold customer if he has purchased at least n orders in the last m months)

1) can be implemented in the validator classes. 2) in an implementation of IEntityValidator. So you're left with 3). As 3) is focussing on cross-entity functionality, it is IMHO best to implement these in classes which consume these entities on which the cross-entity business logic is applied. You could do this in a business object, like a sales order (which contains an aggregated customer object, an order object and several order detail objects for example), but you could also implement it in a data-less manager class.

2- I am a big fan of self-servicing entities because they closely resemble BusinessObjects

a Business Object is defined by BEHAVIOURE, NOT by DATA

and frankly because they are so conveniant. What got me worried is that FRANS discourged using self-servicing entities when remoting is an issue.

Yes, because of the selfservicing functionality . Say you grab an entity from the server, a customer entity, and you access the customer.Orders collection. This would normally load the orders of that customer from the database through lazy-loading. However since you're on the client, it will not work, you should access the server again for these orders. So the functionality you have in your entities for persistence of data is not usable on the client. Therefore the philosophy behind adapter is more convenient in a remoting situation, as the functionality is not there on the client and you have to consult the server for the data/actions you want, which is a requirement in remoting anyway

Ok, you could have a marshalbyref object on the client which calls the server whenever a property is accessed. But you don't want that, as that becomes very 'chatty', which means that the scalability of your solution degrades.

3- Reading LLBL's documentation, I could NOT figure out senarios that we would use UnitOfWork. Could anyone give examples of such cases? Omar

UnitOfWork is an object which allows you to collect actions along the way when you for example walk a wizard or when the user is allowed to perform a lot of actions in a screen and at the end simply clicks 'save'.

Greetings All,

Say you grab an entity from the server, a customer entity, and you access the customer.Orders collection. This would normally load the orders of that customer from the database through lazy-loading. However since you're on the client, it will not work, you should access the server again for these orders. So the functionality you have in your entities for persistence of data is not usable on the client. Therefore the philosophy behind adapter is more convenient in a remoting situation, as the functionality is not there on the client and you have to consult the server for the data/actions you want, which is a requirement in remoting anyway

If I understand Frans correctly, I will assume the following: 1- LLBL's selfservice entities are suitable for creating 2-tier applications only (the BL/DL tier must run in the same AppDomain as the UI). Conclusion: SelfService components would yeild client-server type architecture

2- LLBL's Adapter entities allow the BL/DL tier to run in adifferent AppDomain BUT with the Adapter model I don't get LazyLoading Conclusion: Adapter components would yeild a 3 tier architecture

am I correct in my conclusions.. any explanations are welcomed

OMAR

omar wrote:

Say you grab an entity from the server, a customer entity, and you access the customer.Orders collection. This would normally load the orders of that customer from the database through lazy-loading. However since you're on the client, it will not work, you should access the server again for these orders. So the functionality you have in your entities for persistence of data is not usable on the client. Therefore the philosophy behind adapter is more convenient in a remoting situation, as the functionality is not there on the client and you have to consult the server for the data/actions you want, which is a requirement in remoting anyway

If I understand Frans correctly, I will assume the following: 1- LLBL's selfservice entities are suitable for creating 2-tier applications only (the BL/DL tier must run in the same AppDomain as the UI). Conclusion: SelfService components would yeild client-server type architecture

Not necessarily. N-tier development is not something that is bound to strict rules, it's a state of mind. So if you have separate 'blocks' of code because of their different focus on functionality, you have in fact different tiers. If a gui page reads entities directly but uses a BL class to persist them or do post-form processing, is that 2-tier? I don't think so, but frankly it's not that important either . It comes down to: do I want my gui classes to be able to load/save data directly? If not, selfservicing is not for you.

2- LLBL's Adapter entities allow the BL/DL tier to run in adifferent AppDomain BUT with the Adapter model I don't get LazyLoading Conclusion: Adapter components would yeild a 3 tier architecture

adapter always need an adapter to load /save data but I can do that from a code-behind page in asp.net as well, making it 2 tier .

With adapter however I can make the entity truly separated from the database and the gui totally unaware of teh database it is loaded from. So you can create more abstraction with adapter, as the persistence logic is applied as a service, while in selfservicing is it part of the entity behavior

am I correct in my conclusions.. any explanations are welcomed

OMAR

Here are my 2 cents.

Rule number 1 of distributed programming is to seperate your implementation from your interface.

In self servicing, the implementation is bound to the interface, i.e. you can fetch and save data when using the selfservicing objects. Using the adapter pattern, you have a distinct separation of interface and implementation, whereby your entity classes are your interface, and your service layer classes become the implementation.

Once you have the separation of interface and implementation, the transport is up to you. You could implement pure remoting, COM+, or web services, without having to change your interface or implementation, you simply need to create a services layer for each transport.

Hope this helps.