Skip to main content

Single vs. Multiple Beans

Last Wednesday at the Boston ColdFusion Users group a question came up that was very relevant to an approach I've been taking. The question was basically ' I have a bean (cfc). In it I have all my properties etc. as well as functions that contain my business logic about people in my org. I've also started storing some UI elements as separate functions in that same Bean as well. What are the thoughts of the group?’ I listened closely to the comments because a) I've been doing something similar and b) the room was filled with smart people more experienced than me.
 
Here's my current approach. We are striving to use a clean MVC pattern with each cfc modeling a table in our DB. One of these deals with addresses, say addr.cfc which has all of our logical functions in it to keep them separate from the cfms. In order to comply with our business processes, we have developed an "edit address" form which uses AJAX to communicate with UPS for zip code verification, performs other logic based on whether it is a domestic (US) or international address, uses JS to dynamically set required fields and does form validation before it is submitted. We obviously put a lot of time into that form and surrounding code and naturally want to reuse it.
 
We're using a bean framework so, it seemed to me to make sense to store accessing that form in the same bean as the rest of the functions relating to the address. That has the added benefit of being able to first instantiate the bean then call the form. Two powerful lines of code that I can reuse anywhere.
 
I'll summarize some of the items which were said below and then put how I think I might approach this a bit differently from here on out (and maybe go back and rework some of it)
 
 
Argument 1 (PRO): This makes logical sense. It encapsulates all functions related to that certain bean (in this case an address) in one place which makes it easy to transport, find and access.
 
Response: You can achieve that same portability with other design patterns including a controller, extending beans or using "implement" or an interface and there are other considerations to take in mind.
 
Argument 2 (CON): This is / isn't a pure MVC model
 
Response: I'm not entirely sure that's true. The UI code isn't intermingled with business process. They are in separate functions and each function only contains one aspect of the MVC framework. I have a "save" function which interacts with my DB. I have other functions which perform business logic and others which house these UI elements. There is a "logical separation" even if there isn't a "physical separation" by which I mean they are in different files.
 
Argument 3: That will not scale to large teams
 
Response: Ah, I see. Our history and work experience definitely shape our habits and processes and I realized that the original asker and myself have a great deal in common in that we a) work for smaller organizations and b) tend to wear multiple hats across many levels of development ranging from DB creation to UI in the same work session. It was when I realized this that I came to a conclusion that the my "One Bean" approach needed a slight tweak.
Having one bean works fine if you are a one person shop but if your team grows, it is very possible (likely) that your jack of all trades position will be expanded into more specialized positions. For example, a front end designer and a programmer. It is also very probable that there will be work to be done on both the front end and the back end and if those functions are in the same bean, you are systematically building source control merging issues into your process down the road and who needs that?
 
New Approach: However, I do like the simplicity of having one access point for everything. If we can keep that aspect and solve the "physical separation" issue, that might be the best of both
worlds.
 
Simply put, splitting up the bean into two or three beans and simply extending the "next level" bean.
 
Something like this:
currentname.cfc contains the reusable UI components such as that edit form and extends -->
currentnamelogic.cfc - contains the business logic and extends -->
currentnameschema.cfc - contains the ORM and property information which can in turn extend whatever it needs to extend if anything.
 
Would this cause performance issues? Ben Nadel says no: http://www.bennadel.com/blog/392-Extending-ColdFusion-Components-And-Its-Impact-On-Page-Performance.htm
 
Is this more hassle for small teams than the "one bean" approach - perhaps. Ok, yes. When I'm developing I find it easy to scroll up and down or CTRL-F (can't ALT-TAB between pages in DreamWeaver or ColdFusion Builder) so what I think I might start doing is keep everything in the one bean during active development but just before final test (or someplace near the end where it can reliably tested again) break the single bean into the two or three once the functions are created, tested and ready for launch.
 
Open for Comments
Labels:

Comments

Post a Comment

Popular posts from this blog

Creating Stories and Tasks in Jira: Personas and our Software Development Team

Part of the CI/CD Development Series The next step is developing who is on our hypothetical development team. Given that it has a React front end and ColdFusion as the Server Side language, I came up with the following personas, all of which have their own needs and considerations for our development environment. I've listed all the jobs that need doing, not the people involved since, even on a small team or a team of one, these "hats" are all worn by someone, even if it's the same person. Personas for our Project Dev Ops Coordinator - The person responsible for smooth and accurate deployments CF Developer - The person responsible for the API and fulfillment code development and maintenance. React Developer - The person responsible for the front end development Database Coordinator - The person responsible for the schema, data, up time and, presumably the testing databases used by the developers. Lead Developer - The person responsible for coordinat...
6 comments
Read more

As the Dev Ops Manager, I need to start planning our CI/CD release process

Part of the CI/CD Development Series Once we have our Deployment Diagram designed, we need to figure out out to get from here to there. If the end point is the appropriate server environment, the starting point is the developer with his/her hand on the keyboard. These steps take place on a variety of machines, within various process and can changes based on what files are checked in or not. At the moment, we've only created the early basics as seen below. The Beginning of our Deployment Activity Chart Even though there is quite a long way to go there are some elements which we have already been determined. For example We have determined the broad strokes of our technology stack. This is going to be React on the front end and ColdFusion on the server side. We have determined that we are going to be using linting on both the CF and React paths. CFLint for the CF and ESLint for the Javascript We have determined that we are going to be formatters - CFFormat for CF and...
Post a Comment
Read more

As the Dev Ops Coordinator, I need to set up our git repo into several branches with the appropriate permissions for each one

Part of the CI/CD Development Series The core of every CI/CD process is the code repository whether it be Git, Mercurial, SVN or whatever. The general idea is that it allows multiple developers (or whomever) to access your code in the appropriate way in the appropriate level. This can either be the ability for anyone to pull an open source project but not write to the repo directly or full access to a developer on your team to create branches, push to master or anything that needs doing. For our project, we're using git although the hosting provider was up for discussion between Github, Bitbucket by Atlassian or CodeCommit on AWS. We decided to go with AWS for two reasons. 1. We are going use other tools in AWS as part of the build so we decided to keep it all together. 2. We needed to solidify the ins and outs of using IAM for the process. Basic Steps Create the Repo Create the branches we need Use IAM to apply the appropriate permissions to each branch and to set up ...
1 comment
Read more