I am trying to come up with some naming, coding and design standards/
conventions. Things that should be followed by me as well as other
developers I work with. Each time I think I Have a convention down, I
seem to run into some new use-case that changes that convention. Right
now I am working on an online store, doing it the “proper” way using
UML use cases and all that good stuff first. Making the thing somewhat
proper Object Oriented. I really want to get some OO standards down so
that new projects can be developed properly and rapidly. I am hoping
to get some opinions on the current standard I am thinking of working
with and ironing out some uncertanties. Any input would be greatly
appreciated!

Check out http://sqrl.wordpress.com/2008/06/20/naming-coding-design-standards/
for a better formatted version of this message.

Problem 1 - Naming Conventions

Current Guidelines:

    *
      Variables that represent an id are spelt “id”. Lower case like
that. This means:
          o myObject.getId()
          o Table column = id
          o This rule is in place because “Identifier” is not 2 words,
so why should ID be 2 words?
    *
      Names that are 3 characters or longer are lower cased.
          o URL is url
          o XML is xml
          o
            DAO is dao
                + This is where my current problem is, should this be
DAO or dao? What looks more natural to you when seeing a CFC name or a
class name in a UML diagram: CustomerDao or CustomerDAO?
    *
      This vs this vs THIS…What would you use?
          o
            Would you use the same format for all other built-in
variable scopes (i.e. Variables, URL, Form, Client, …)

      Problem 2 - Architecture Conventions

      My next problem is more about coming up with a base architecture
that can be followed. Right now, this is what I have thought of for
the Customer entity in this store:
    * Customer
    *
      CustomerService
          o Calculations and other operations go inside here.
    *
      CustomerDao
          o I removed the CustomerGateway in favour of putting
everything into the DAO. Perhaps this was a bad idea?
    *
      CustomerDaoConnector
          o This would be where all the actual cfquery tags are. The
DAO would call the methods in here to get the query data and then the
DAO would convert the query data into an array of objects. I know
there is debate out there of whether a DAO should return queries or
objects, I feel though that it is best to return Objects because then
if something needs to run on the object, such as a composite variable
(e.g. Customer.name returns Customer.firstName and Customer.lastName)
then it can do so. So for the purpose of this article, just know I
want the DAO always returning objects, never queries. The queries
should go in CustomerDaoConnector.
          o
            That said, would CustomerDaoConnector be better named
CustomerDaoSource? This comes from the shortened version of
CustomerDataSource….although maybe CustomerDataSource would be a
better name? What do you think, which 1 of the below sounds best to
you, or should these functions just be part of the functions in the
Customer DAO?
                + CustomerDaoConnector
                + CustomerDaoSource
                +
                  CusomerDataSource
                      #
                        My only problem with this is that this data
source object is going to be fairly tightly coupled to the DAO, since
the data source on it’s own shouldn’t be used anywhere else. So when
looking at files it’s kind of nice to see CustomerDao and then right
below it CustomerDaoConnector. I kind of like the sound of
CustomerDataSource though…what do you think? The “Data Source” object
name came from the diagram at 
http://java.sun.com/blueprints/corej2eepatterns/Patterns/images09/figure09_01.gif
which was contained in 
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html.

      Before I start building this application I would like to have
these conventions down pat. The more input everybody out there has,
the better!

      Thanks!

      Greg

Coming Soon…UML Diagram of what is currently there. Stay Posted.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to