Best Coding?

[Guest]

Okay I have a question about using CFC's.
I'm building an app and it contains several modules. Each module has it's own CFC.

Right now I have in the application.cfm the following line:

<cfset Application.clients  = createObject("component","modules.clients.cfcs.client")>

To call any function I can just use the Application.client."function"()

Now these cfc's have been getting bigger and will be getting bigger in the future.

My question is should I keep doing it this way or should I use the <cfinvoke> to call these functions.
I'm worried that the performance will take a hit. I have been looking into the MySQL procedures,

which should help out with the performance, but I'm not sure if keeping it in the application.cfm is the

right thing to do.

Anybody has some thoughts about this?

Thanks

[Owainnorth]

Depends what they're doing.

Personally, I keep all mine in the Application scope. That way when I need to use one it's already been read, parsed, compiled and stored in RAM so it's as fast as can be.

The only thing I would ever change was if you had a CFC which is simply doing a massive amount of database work - that I'd move to a stored procedure, but would still call it from the Application scope.

I actually have gone one step further and written myself a ComponentManager which sits in the Application scope and caches my CFCs as and when they're required, rather than having to initialise them all on Application startup. I kinda do:

<cfset qCustomers = application.ComponentProxy.getManager('Customer').getAllAsQuery() />

The ComponentProxy has a hashtable of components, when I call my getManager method it checks to see if it's already cached (and caches it if not) then returns a reference to it.

Overkill, probably. But it works

Just don't call anything "CLIENT", whatever you do...

[Guest]

Owain,

Thanks for your reply.

Let me explain more on what's going on. I'm making this app for  companies in europe that their customers can use to register complaints.

My customers are construction companies, painting companies etc.

Their customers are like housing coorporations, schools hoa's etc.

Now for each group (hoa's, schools etc) i'm making a different module within the app.

Each module has it's own cfc to retrieve information, complaints (and attached to the complaints, actions, documents, pictures etc), add delete and so on.

Now that I'm done with the first module, I realized that one of the CFC's s like 3000 lines long. (and this is just the beginning)

I have been looking at my queryies and trying to  optimize them. Still it's a lot of info that's being put in the application scope. If I look into the future their might be in total 7 more modules, and maybe other things added to the app. So it's not just staying with 2-3 cfc of 3000 lines.

Also this app will hold the information from the customers for several years, which the dbase could get pretty big.

As I was going over the app code again, I started to worry if I would get stuck at one point, with the way I was doing this and that the performance would get a hit. At the point that I'm at now I would rather change it than later on.

I like your idea about the ComponentManager, but do you unload the cfc's when your done our do you leave them?

I've been coding with ColdFusion for a while now but there is a lot I dont know yet.

For instance how can you find out how much memory your cfc is using?

Thanks

ps. Sorry for the bad word choice "client". I used it as an example, not thinking how others would read it.

[Owainnorth · Accepted solution]

No, I never unload them - once they're there I leave them there until the Application is restarted.

Putting stuff is not a problem as long as you have RAM - bear in mind however that even 3000 lines of code can compile down to a bare minimum of memory usage, possibly only 10's of kilobytes if that.

I'd just monitor the RAM usage of CF as time goes on, but bear in mind having it in the App scope you only ever have one copy - if you were to be constantly unloading and reloading CFCs in people's sessions you'd actually end up using *more* memory and running slower.

If the Application itself gets too big to be manageable, I'd consider splitting it up into separate Applications, rather than separate CFCs.

As long as your database tables are properly set up and indexed, having years of data is no problem at all. There's no simple way of seeing how much memory a component is taking up, but you can get a rough idea by trying to locate your cfc in the CF cache directory (E:\CFusion\wwwroot\WEB-INF\cfclasses or thereabouts) - that's where the compiled templates are stored.

O.

[Guest]

Owain,

It makes sense what your saying. Unloading / reloading, would put more load on the server, than having it load once.

I found the folder and will be able to tell how much it could be using. At least it will give me an idea.

I do have to do some finetuning, but think it will be fine. And like you said if it gets to big / unmanagable, just split it up.

I learned some new things. Thanks for responding to my post.

[Owainnorth]

No problem at all, happy to help. There's nothing to say someone else won't come along with a different opinion!

O.

[Dan_Bracuk]

Regarding "There's nothing to say someone else won't come along with a different opinion!"

That would be me.

According to the OP, there are several modules, each with it's own cfc.  These cfc's are growing all the time and one of them is over 3000 lines long.  This makes me wonder how much code repetition is taking place in these cfc's.  If there is a lot, I'd be looking at ways to reuse that code instead of repeating it.

[Owainnorth]

I wouldn't say that's a different opinion, that's just good coding sense

Obviously yes, all the above are concepts. Writing good code is a different matter.

[Guest]

I understand. There is a lot of code. The reason why it's so much, it's because for instance the schools, all the functions are in one CFC.

This is to retrieve basic information about the schools, complaints, actions to that complaint, docs per complaint  etc. Everything related to in this case the schools. The reason I did this, is that if I had to make a change to the module schools, I just look at one CFC.

The only thing that I could look into is the registration of the complaints. Although for each module (school for instance) the way the information is registrered is different.

One thing I might look into is that I have a lot of tables that are linked to each other. Because these links I have to write longer / more queries.

Maybe an option is to registrer more info in one table. This way when they retrieve the information, it comes from one dbase instead of 3-4.

[Dave Watts]

I have to say, I really strongly agree with Dan here. You should NOT have 3k lines of code within a single CFC. That is a clear sign that that CFC is doing too much stuff. Exactly what part is the "too much" part is something you won't get without additional experience or a code review, I suspect.

Dave Watts, CTO, Fig Leaf Software

http://www.figleaf.com/

http://training.figleaf.com/

[Owainnorth]

Maybe, maybe not. Having a look now, my largest is about 1500 lines long and whilst I agree 3000 is a big ol' cfc, that's not to say categorically that it's badly written.

Absolutely it should be reviewed to see if the code can be better formed or queries improved, but that goes for absolutely every part of an application all of the time. I have Manager/Gateway cfcs that can simply need lots of different queries to retrieve different sets of data of the same type - every time a different query is needed and I can't simply add an argument to an existing function, another one gets tagged on.

I don't see why a 3000-line CFC should have any kind of performance defecit over ten 300-line ones, after all it's just memory addresses.

If the code is badly written I agree that's a different matter, but is not the subject of the thread.

[Guest]

Okay I understand where everybody is coming from. And yes there are probably some improvements that can be made, but I have to agree with Owain. What is the difference between 10 300 lines of cfc to one 3000 line cfc.

My question to everybody would be then for an application how many lines of code is reasonable in all the cfcs combined.

To shed more light on  my app I have for instance two tables for the Housing Coorporations. One with the housing coorporations info and the other with  the objects belonging to this coorporation. These are some basic retrieve functions in the cfc.

Now looking at the complaint part. I have a table with the complaint, one with actions to that complaint, one with additional info to that complaint, one with pictures for this complaint, one with documents for this complaint.

Now I could move some of the info to the complaint table, but doing this would mean the minute someone for instance adds a picture I have to add lines of code to the cfc to actually add this info to the complaint table. So to me this basically mean move one part of code out of one cfc to the other cfc, which does not help to much with minimizing the code. I agree that less code is better.

I have looked at my cfc and I see some parts that could be improved. But I wont be able to bring it back to 1500 lines of code.

The only way I have seen so far to bring down the lines of code is to create procedures in MySQL. Then the query is in the procedure and not in the cfcs.

Also to be realistic I have a lot of commenting going on in my cfc so that if I have to look back later I know what I did. (per function 1-2 lines of comments).