Frans,

You have put a lot of hard work into LLBLGen Pro - and it shows. I'm a recent convert to your tool. I run a large Pocket PC Development community called DEVBUZZ.COM and started a thread giving LLBLGen Pro a plug here:

http://forums.devbuzz.com/tm.asp?m=28744&p=1&tmode=1&smode=1

I'm using LLBLGen Pro for a desktop project and I'm struggling to adapt my n tier architecture to make the most productive use of LLBLGen Pro and need some advice.

My issue is similar to the BL discussion in this post:

http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=223

My Q: Previously my architecture consisted of a set of BL classes which contained my data access layer, which were consumed by various forms. Since I will reuse the BL classes in web services and other applets I need to decouple them from any Forms (otherwise I would use your suggested Manager class approach.) I need a technique where I can inherit the BE classes so that I can extend them but before I know it I will end up reengineering my own collection classes and classes from the BE classes and that really seems like a waste of effort esp since LLBLGen Pro does such a class act (excuse the pun) of doing this work for me. It seems to me that you are suggesting the two class approach rather than the inheritance approach? Is that correct? Can you suggest any alternative implementations?

Regards Derek

DrM wrote:

You have put a lot of hard work into LLBLGen Pro - and it shows. I'm a recent convert to your tool. I run a large Pocket PC Development community called DEVBUZZ.COM and started a thread giving LLBLGen Pro a plug here:

http://forums.devbuzz.com/tm.asp?m=28744&p=1&tmode=1&smode=1

Thanks for the plug, I saw it in my referers indeed Btw, pocketpc support for SqlServer CE is in the pipeline, stay tuned.

I'm using LLBLGen Pro for a desktop project and I'm struggling to adapt my n tier architecture to make the most productive use of LLBLGen Pro and need some advice. My issue is similar to the BL discussion in this post: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=223 My Q: Previously my architecture consisted of a set of BL classes which contained my data access layer, which were consumed by various forms. Since I will reuse the BL classes in web services and other applets I need to decouple them from any Forms (otherwise I would use your suggested Manager class approach.) I need a technique where I can inherit the BE classes so that I can extend them but before I know it I will end up reengineering my own collection classes and classes from the BE classes and that really seems like a waste of effort esp since LLBLGen Pro does such a class act (excuse the pun) of doing this work for me. It seems to me that you are suggesting the two class approach rather than the inheritance approach? Is that correct? Can you suggest any alternative implementations?

I think you are in doubt which of the two (domain model (fowler) or manager model) you have to pick. Domain model is build around the idea that for example the 'OrderEntity' object initially generated is extended through inheritance to add BL logic to that class. The manager model is the other way around: that's based on 'consuming' data oriented classes like entity classes in logic which is stored into classes which are empty besides logic.

If you are going the domain model route, you definitely want to use adapter, as it is far more suitable to support inheritance. The selfservicing templates are pretty much limited to the two class scenario when it comes to inheritance.

If I may add a personal note: in my experience I've always found it more comfortable to work with the manager approach (which thus defines classes in the BL tier which consume objects with data supplied to them by another layer (thus not included in that layer) as much processes in organisations are procedural, which then makes it easier to make the projection of the functionality definition (the organisational process) to the code as you can do that almost on a 1:1 basis.

The manager objects expose a functionality set to the layer(s) on top of them, for example a set of gui tiers. So they are re-useable.

Frans,

Thanks for the advice. My heads spinning a little at the moment having just read the following section in the docs:

Generated code - Extending the framework through inheritance, Adapter

I definitely want to go with the domain model approach; but the Adapter template group verses SelfServicing has me a little confused. I understand how the 2 class templates in Self Servicing classes support inheritance but how does the Adapter template make inheritance any easier. The docs I read (ref above) make my brain hurt. Admittedly it has not been used too much recently (back from a 5 week holiday ).

Cheers Derek

DrM wrote:

Thanks for the advice. My heads spinning a little at the moment having just read the following section in the docs:

Generated code - Extending the framework through inheritance, Adapter

I definitely want to go with the domain model approach; but the Adapter template group verses SelfServicing has me a little confused. I understand how the 2 class templates in Self Servicing classes support inheritance but how does the Adapter template make inheritance any easier. The docs I read (ref above) make my brain hurt. Admittedly it has not been used too much recently (back from a 5 week holiday ).

Whoa 5 weeks Lucky you

Selfservicing is able to be self servicing because everything is tied together. So if you want to extend OrderEntity to MyOrderEntity, you also have to write MyOrderCollection and inherit every other class which contains an order collection if you want to expose MyOrderEntity objects in a collection like customer.Orders.

This is rather complex and getting rather complex very rapidly if you want to implement a huge inheritance tree with selfservicing. that's also why I supplied the two class scenario so you already have a derived class you can alter/add code to.

Adapter is more cleaner, becuase a lot of code is generic. This is possible because everything is persisted through the adapter object plus it has a general collection class, not a typed one (which is not required either because it doesn't have type specific filters in the collection object also).