Csla List Naming conventions

Csla List Naming conventions

Old forum URL: forums.lhotka.net/forums/t/5584.aspx


decius posted on Tuesday, October 14, 2008

When possible, I like to make an effort to stick as closely to a communities naming convention as possible.  I am curious about the naming conventions for Csla Lists (i.e. those found in ProjectTracker). 

I thought I understood, but it seems I don't: what's the difference between these two conventions?

  1. ResourceAssignment and ResourceAssignments
  2. ProjectInfo and ProjectList

JohnB replied on Tuesday, October 14, 2008

ResourceAssignment is a BusinessBase object
ResourceAssignments is a BusinessListBase object.

ResourceAssignments is a collection of ResourceAssignment objects

ProjectInfo is a read-only object
ProjectList is a read-only collection

ProjectList contains a list of ProjectInfo objects.

HTH,
John

decius replied on Tuesday, October 14, 2008

fabulous, I had just been using List and Info suffixes for ALL Csla Lists.  That helps a lot, thanks!

decius replied on Tuesday, October 14, 2008

One last question:

But what happens if you have a need for a Parent BusinessBase version of Resource?  What would that class be called since the name "Resource" is already taken by the child of Resources?

decius replied on Tuesday, October 14, 2008

It seems to me that this naming convention will ultimately clash like so...

How are people avoiding this issue?  At first I figured to just add an additional Get factory method to Object that goes through the DataPortal, but I think that would be unintuitive for the UI Developer.... any thoughts?

 

Michael Hildner replied on Tuesday, October 14, 2008

I'll just throw out what I do, FWIW.

I like to look at the class names in the solution explorer and know what the object does. So I suffix my bo's like:

CustomerER - editable root

CustomerRORL - read only root list

CustomerROC - read only child

CustomerERL - editable root list

etc.

Mike

decius replied on Tuesday, October 14, 2008

I like that, I might adopt this actually as it solves my problem.  However, I hate to stray from the mainstream's established naming conventions.  I also found this thread useful, though it also didn't address the problem i mentioned in my last post

http://forums.lhotka.net/forums/thread/18044.aspx

 

triplea replied on Tuesday, October 14, 2008

Out of curiosity, what convention do people use when you have the following within the same namespace:

ProjectInfo (read-only object)
ProjectInfoList (read-only collection of ProjectInfo)

Project (BusinessBase object)
ProjectList(BusinessListBase collection of Project)

I use the above info bit in my read-only list but maybe there is a more elegant convention...

sergeyb replied on Tuesday, October 14, 2008

I use the same one as you – adding word “list” for BLB and ROLB classes.

 

Sergey Barskiy

Principal Consultant

office: 678.405.0687 | mobile: 404.388.1899

cid:_2_0648EA840648E85C001BBCB886257279
Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

 

From: triplea [mailto:cslanet@lhotka.net]
Sent: Tuesday, October 14, 2008 9:46 AM
To: Sergey Barskiy
Subject: Re: [CSLA .NET] Csla List Naming conventions

 

Out of curiosity, what convention do people use when you have the following within the same namespace:

ProjectInfo (read-only object)
ProjectInfoList (read-only collection of ProjectInfo)

Project (BusinessBase object)
ProjectList(BusinessListBase collection of Project)

I use the above info bit in my read-only list but maybe there is a more elegant convention...



ajj3085 replied on Tuesday, October 14, 2008

I use a plural name for BLBs, and List suffix for ROLB.  So Prices is an editable list of Price objects, and PriceList is readonly.

decius replied on Tuesday, October 14, 2008

thanks for the input ajj3085, but what about when you need to create both an Editable Root and an Editable Child in the same namespace like so:

 

ajj3085 replied on Tuesday, October 14, 2008

I had something kinda like that come up.

I had a PriceList, which contained a list of pricing data; a price for every product in the system.  I chose to use ProductPrices for it's BLB and ProductPrice for the BB.  Then, in the Product class, I simply had a Prices child BLB which contained Price BB. 

It makes sense (to me at least); a price list is a list of prices for products, and a product has a list of prices (one price for each list in the system).

So, I think I kinda used the use case to help give a more specific name than the ones I had orginally chose.

decius replied on Tuesday, October 14, 2008

thanks for the input ajj3085, but what about when you need to create both an Editable Root and an Editable Child in the same namespace like so:

 

Copyright (c) Marimer LLC