Hi there,

At the moment my solutions have projects for UI, Business Layer and then the LLBLGen projects.

The business layer is where all of my LLBLGen Adapter type code is and it also does things like composing ecommerce orders i.e. sending emails, building up object hierarchies etc.

Now it occurs to me that there is a significant different difference between composing an ecommerce order and method after method of LLBLGen queries so I was thinking that maybe the queries should go into separate project - perhaps behind a repository interface! Whatever the theorists says I reckon my code would be a lot more cleanly organised. The question is where does one draw the line as to what LLBLGen code goes in the repository and what goes in the Business Layer?

So for example... lets say I want to email a list of accounts. So I request the accounts from the accounts repository and then iterate over them in the BL sending an email to each one. Within each iteration I construct an entity which represents the sending of the email. I think that the 'email sent object' should be created in the BL and then the account should be saved by the repository. But surely there are times when the repository will create the odd new entity and do its own object composition? I'm not sure! Any ideas? I think an interesting insight is that this distinction in layers used to be _forced _upon us when we used stored procedures. The queries that we currently express with LLBLGen used to be written in SQL at the database. They were well out of the way!

One further question... should the UI have direct access to the repositories? If not then surely there'll be a lot of methods in the BL that do nothing other than delegate to the repositories.

Cheers, Ian.