More than one CSLA Class Template per Entity

Jul 12, 2010 at 1:12 AM


In some scenarios, it might be desireable to have more than one CSLA class generated for a single Entity in the EF model.

For example, one might want to generate CustomerInfo + CustomerInfoList (ReadOnlyList) classes in addition to a CustomerEdit class (EditableRoot).

What do you guys think ?

Jul 12, 2010 at 2:05 AM
Edited Jul 12, 2010 at 2:05 AM

Just forgot to mention that I already have the UITypeEditor ready. I'd just need someone to work on the actual T4 template =)


Jul 12, 2010 at 7:22 AM
We already had that request and I think we should do that for the Beta3 release. We can discuss implementation details because it's not a simple task. There is a problem with entity relations, because we don't know which generated class to use in related properties.
Jul 13, 2010 at 4:01 PM

The scenario that I can think of is where we need to generate an "info" class along with an "edit" class.

Generally, an info class will not have navigation properties. Or maybe you're talking about something else ?

Jul 14, 2010 at 7:47 AM
Edited Jul 14, 2010 at 7:48 AM
Let's say we have Orders and Customers entities in our EF model. Our generated Order class will have a related property Customer. If we generate Customer editable root and CustomerInfo read-only root classes, which class will be used for the Customer property of the Order class? Other problem is that in most cases read-only class does not have all the properties of an entity, or even worse, it has some properties from related entities (eg. Customers have a relation to the Countries entity and you want to display Country name). Recommended pattern is to create a database view "CustomersInfo" and use it to generate the read-only class. On the EF model you can delete existing relations to the Customer entity and add relation to the CustomersInfo entity. That way you can model your editable root and read-only classes separately.
Jul 14, 2010 at 1:17 PM

Ahh.. I see what you mean now.

So you deal with this issue by using views for the read-only classes ? <

I guess you could also have an EF model for editable classes, and another model for read-only classes. It depends if views can be created in the DB (some DBAs like to have the final word).

Jul 14, 2010 at 1:55 PM
Yes, I'm using views for read-only classes whenever possible. That way I can model read-only classes to include only necessary fields from the database. When this pattern is not possible, I can always add new class manually and write custom code. If I can generate 80% of the code in my app that's good enough for me now. This scenario is something to think about for future versions.
Jul 18, 2010 at 6:00 PM

What about the cases where you have the following:

Customer (EditableRoot) --> Orders (EditableChildList) --> Order (EditableChild)

but you also want to have:

Order (EditableRoot)

I can see this happening if you want to edit orders on a customer level or add individual Order items. Maybe introduce a way to create multiple objects per entity?

Jul 19, 2010 at 2:15 PM
Edited Jul 19, 2010 at 2:15 PM

Hi Andreas.

It is not recommended to have two editable objects for the same scenario (in your case that scenario is editing of the Order object). If you have two different classes for editing the Order, you would need to write the same business rules and a lot of other code twice. In your case I would recommend using the Switchable template (object that can act as root or child). We did not implement that template yet, but it will be done soon.

Also, I would consider using read-only list of orders for Customer->Orders property, and when selecting one order for editing, I would load one editable Order object and display it for edit.

Jul 19, 2010 at 11:33 PM

Thanks for your reply. Maybe my example was not great but I have encountered many occasions where multiple objects per database entity need to exist. The objects share properties, basic rules (e.g. max length etc) and data access code but business/authorization rules are distinctly different. I just think that the 1-1 link of objects-DB objects (even with the view-readonly object combination) might be a bit limiting. Maybe this is just me :-)

Jul 20, 2010 at 11:35 AM
Edited Jul 20, 2010 at 11:36 AM
No problem, we will think about this issue for future releases. The scenario you described above can be solved by using inheritance. I would generate one editable Order class and then inherit that class in order to change it's behavior. That way you can create InternationalOrder class, or TaxFreeOrder class etc.
Jul 20, 2010 at 1:41 PM
Edited Jul 20, 2010 at 1:41 PM

One thing that we must not lose sight of is the fact that CSLA Business Objects are, or should be, "Use Case Specific".

What I mean by that is that if your use case calls for edition, then your BOs will be built around this scenario. We must take great care not to try to create every BO classes within the same use case.

One way is to have a use case container. What I usually do is to separate my use cases into separate projects. Inside each projects, I have one or more EF models from which I generate my BOs for the current use case. For example, I have one model for my Editable BOs, and another one for my Info BOs. If some Info BOs are needed by more than one use case, then I refactor them out into a separate project than can then be used by the others. This works well with frameworks such as SCSF or Prism.

I think it would be a mistake to try and generate too many BOs out of one single EF model. other than maybe a few basic scenarios. This is where we need to focus our attention and efforts IMHO.

Jul 20, 2010 at 4:08 PM

@mrlucmorin: Thats quite an interesting idea actually but wouldnt you sooner rather than later end up with too many EF models? How does that scale in your projects?

@jbudimir: IMO inheritance should be avoided. Actually I remember Rocky in numerous occassions also commenting that it is not worth introducing tight inheritance coupling and that it is preferrable to sacrifice 5-10 minutes of repeating property/DAL code (which thanks to this extension we can generate anyway :-) )

Jul 21, 2010 at 5:03 PM
Andreas, Generally, I only end up having 1-2 EF models per project. The way I split my application with SCSF is to have one module (VS project) per use-case. So yes, the Solution has many projects (each one a module that gets loaded by SCSF), but each project only has a few EF models. I guess that's the price one has to pay to work with EF. In the DataSet days, it wasn't rare to have dozens of different DataSets in an application, each one taking care of a use-case. Since EF won't allow you to map to the same table twice (not entirely true, but...), you don't have much choice if you need this kind of multiple mapping but to have more EF models involved. I tend to stay away from large monolithic applications where I'd end up having dozens of models and so on in the same project. I prefer splitting my app in multiple projects and have the resulting modules loaded at runtime.