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
Comments
Post a Comment