Hi Everyone,

I'm relatively new to LLBLGen and I'm just wondering how to better write code to enable some re-use or modules.

An example I can think of at the moment would be an Address Entity. Over all applications that it's used in it will have a consistent class or DB Structure (Name, Address Line 1, Suburb & Postcode). I've also built a really simple user control that displays the information and also querys a postcode table populated with all standard suburbs and postcodes to autocomplete entries.

My question is what's the best way to put the Address Entity, PostData Entity and user controls etc in a library project/solution and then reference the Address Entity from say a Customer entity which may have a Physical and Postal Address (and so the related FK to the Address Entity / Table) from the actual DAL in the final application?

LLBLGen would generate the FK properties for me - but how would I go about linking the actual entities together (and also using them with complex queries such as find all Customers that have an Address in Postcode 1234)?

Normally I'd just create a relation like:

Dim relationsToUse As New RelationCollection()
relationsToUse.Add(EntityClasses.CustomerEntity.Relations.AddressEntityUsingFkPhysicalAddressId)

Any insights on this would be much appreciated!

My question is what's the best way to put the Address Entity, PostData Entity and user controls etc in a library project/solution and then reference the Address Entity from say a Customer entity which may have a Physical and Postal Address (and so the related FK to the Address Entity / Table) from the actual DAL in the final application?

You can include the User Controls and any related code in a library.

But the corresponding tables should be there in the catalog when generating the code, so that relationships can be built in in Entities referencing AddressEntity.

I guess in this case I would have 2 catalogs:

• One for the postal lookup tables which my application doesn't need to know about.
• Another to hold Address & Customer information.

The User Control library would need to know about an Interface that the Address Entity would have to implement - as it has to display the various addressing fields.

This seem like the best approach to you guys?

Indeed.

I see that simple: you have a AddressControl.ascx for example. That control takes care of receive an Address and edit it, create new addresses, display address info, etc, all of that according to the user input or the values the page send to the control. So for example if you have a CustomerEditPage.aspx and in there you can edit the addresses, the control can take care of it, and just before save the customer you could write something like

// here, TheAddress is a property of the control that exposes the involved entity on the control
thisCustomer.ShippingAddress = myAddressControl1.TheAddress;
thisCustomer.BillingAddress = myAddressControl2.TheAddress;