Good afternoon all,
I am wondering what folks are using for naming conventions for CSLA objects. I am running into a minor problem in that we have so far avoided the situation where we had readonly and writeable objects that acted on the same database table, but now I am precisely in that situation.
I need to update data in a table called individuals and we already have 3 readonly objects for that table called individual, indivudualInfo, and IndividualList. Our convention has always been to use the Info extension to show that this object is meant to be used as a list member and the List extension is obviously a collection of Info objects. The object without any extention, Individual, is not intended to be part of a collection, instead it represents just a single record. Again, the 3 existing objects are read only and are used by several applications that do not need to edit the data.
Now I need to create new objects that update the database table called Individual, and I will need a collection object and an object that will be used to fill the collection. Obviously I can't call my new objects IndividualInfo and IndividualList and keep them in the same namespace, although that is exactly what I need to do.
I don't want to change the existing objects to be writeable because I don't know what problems that would cause in the apps that use them. Plus, the existing object only pull those columns that are needed to describe an individual. But the Individual table is in a proprietary DB and has another 50 or so columns that are not used by our read-only objects. In order to update a record in this table, I have to use a stored procedure provided by the database and it requires that I send all column values, both old and new values, when I update the row. So I really don't want to modify the existing objects to include all the columns in the table because they don't need them and I don't know how that will affect the applications that use the objects.
So what do you do to help distinguish objects that are read only and those that are read/write? I could just add RW to the name, but I am hoping you have a more "standard" or "conventional" suggestion.
BTW, by read/write object I mean an object that inherits from BusinessBase or BusinessListBase while a read-only object is one that inherits from ReadOnlyBase or ReadOnlyListBase.
Thanks
URW
My Editable Bos use the names you gave to your existing Read Only BOs.
My Read Only BOs have the suffix RO and ROC on them.
ROC takes the place of "List".
So I would have:
Individual - Editable Root
Indiviuals (or IndividualECC) - Editable Child Collection
IndividualInfo - Editable Child (nested inside ECC)
IndividualRO - Read Only (stand alone)
IndividualInfo - Read Only (nested inside ROC)
IndividualROC - Read Only Collection
Joe
My suggestion is to look through the .NET Framework classes provided by Microsoft for naming suggestions. It is my preference to adhere to the guidelines provided by MS and used in the FCL. You will find this is especially useful (and required!) when sharing your code with other developers. This may or may not apply to your situation (today), but it is still a good idea to adhere to industry standards as best as possible.
With that in mind, there are a few areas where you won't find MS conventions helpful, such as differentiating between the various CSLA classes. Here you will find many preferences.
In my case, I try to keep it simple (I'll use Project to make it more tangible):
| Project | editable object (root) |
| ProjectList | editable collection of Project items |
| ProjectInfo | read-only object (root) |
| ProjectInfoList | read-only collection of ProjectInfo items |
| ProjectResource | editable dependant (child) object |
| ProjectResourceList | editable collection of ProjectResource items |
In other words, the following convention:
| [Root] | editable object (root) |
| [Root]List | editable collection of [Root] items |
| [Root]Info | read-only object (root) |
| [Root]InfoList | read-only collection of [Root]Info items |
| [Root][Child] | editable dependant (child) object |
| [Root][Child]List | editable collection of [Root][Child] items |
Of course, MS would recommend that you use a "ReadOnly" prefix instead of the "Info" suffix, but this is a convention that I prefer because it results in shorter names and allows objects to be grouped together in the Solution Explorer, but I would acquiesce to other's preference to use the "ReadOnly" prefix (e.g. ReadOnlyProject instead of ProjectInfo).
HTH
![Big Smile [:D]](/emoticons/emotion-2.gif)
skaue:
Unless I've missed something, thats a pretty long list of types for just 3 businessobjects.
If you have use cases requiring read-only and read-write access to all the data in all the objects, then that's probably what you end up with. Not all apps need read-only access to the entire set of data like that though - often some of the read-only access ends up in NV lists instead, which is simpler.
In many projects I use namespaces to seperate read-only and editable objects. That helps make intellisense more useful.
Sure, just like that.
MyApp.Edit.CustomerEdit
MyApp.Edit.CustomerEditList
MyApp.View.CustomerInfo
MyApp.View.CustomerList
Or whatever fits into your namespace model.
Rocky
From: skaue
[mailto:cslanet@lhotka.net]
Sent: Thursday, October 04, 2007 2:34 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Naming Conventions
You're probably right, Rockford. The namespace-tip might
come in handy. Could you give an example?
Would it be like Company.Solution.BO.Readonly.BuildingList and
Company.Solution.BO.Editable.BuildingList?
Copyright (c) Marimer LLC