More conventions needed, have asked since 2.6.3

Communities ColdBox HMVC
1

Well I am one who likes to keep things separated, and to this date I have asked a number of times to no avail on the subject of services.

Currently I have the following directory structures

->wwwroot

->entities

->models

->services

Now it is very straight forward that all my domain classes (or ColdFusion entities) are stored in the entites folder, and models folder is anything that is business logic and the like. Whereas services are just that, all my services.

I asked when 2.6.3 was released, and again when 2.6.4 was released if we could have these conventions.

And now we are going into a 3.5 release with these convention still not added, or are people very happy to keep their application model, entities and services in the one directory?

And the reason Entities is a separate directory, is because some of my applications are huge. And if I can keep ColdFusion from inspecting as few components as possible then I will, I don’t think a convention is needed here, it’s a matter of remembering to add it to the application.cfc, but when it comes to services I would like to see a convention added……

Pretty please Luis…

2

WireBox can support you with the use of scanLocations. Most of us do not share your conventions.

3

You know that is very presumptuous of you Aaron, the ColdBox team is a minority and how do you know that all the users of ColdBox don’t share that view? After all they are forced to not have it, which is why I asked for it and have added code to enable it for me.

But I think separation of the code is far better than the current method, especially when it comes to scanning of components that do not require DI, like normal models or business logic. These files will end up being the majority of peoples applications.

Once you start throwing Models, Entities and services into the same directory. You are essentially saying that the length of time to scan that directory and do its DI work, is time consuming on the framework.

Hell on some of my applications, hibernate throws a time out error because of the scanning of some of the components, and is why I moved to separation of them.

That’s fine with me, if you believe that a performance issue can’t be solved in this manner then that’s fine, I am happy to continue developing my way and make everything incompatible with the rest of the community.

4

Aaron,

To give you an idea on how and why my ColdBox application used to time out, lets break down the number of files that used to be in the one directory. Which is what everyone seems to be going with, only because they don’t know or are just following the leaders.

ColdFusion Entities 238 files
Services 60 files
Model and beans and the like 300 files

Modules

5

So why don’t u create the separation inside your models folder? By creating folders?

Cheers,
Tom

6

First of all entites recurse, thought you would know that.

Secondly, I would prefer to follow the grails approach and keep services by a convention. If you know how grails structures there files then you would know what I mean.

Its not a hard request, most MVC frameworks outside of ColdFusion adopt the separation of the model into layers, all I am asking is for it to come to ColdBox as well.

7

Well honestly, I don’t like entities to begin with. I avoid orm for anything more then simple inserts and updates. Specifically in big systems with large dbs. 238 entities would count as a large db and in my opinion that is asking for trouble on both the web server and the database server…

But then again I don’t know how you program or where u use orm so I will not judge.

I would rather use a bean and create my own data access layer. That way keeping an eye on both the recursive behaviour and the ability to optimise my queries the way I see fit.

Therefore my model folder would be split into layers by using pofo (plain old folders :stuck_out_tongue: )

So a convention like you suggest would not benefit me in any way.

What you could consider is a module that creates this convention as an extension of the usual coldbox configuration. So that people can use it if they see fit. Could be a nice project: grails-conventions module.

Cheers,
Tom

8

Well I already have an interceptor that already does it, problem is that if I release any of my projects as open source they will not be compatible with other peoples. As all modules that I am writing and have been working on for the last 3 years, follow this convention.

Guess that’s the grails side of me where I want my services separated from my application business logic.

As for ORM I love it, but its not the problem here. As I can move this into other folders as I do, but if you look at all the code that is being release like ContentBox, it is saying the best place to place your entities is in the model folder. Once you start working on larger applications, as I have done then there is a performance hit because CF will time out when trying to inspect all those CFC’s so I am saying it with a grain of salt, either ColdBox adopts the same conventions as grails and separates the logic, everyone else who starts to release large applications will fall into the same category / problem its just a matter of time.

And I personally do like my services also away living in its own directories the same as grails does it, its neater and you know what files are services and what are not, yeah we can always end the name of the file with Service, but that’s not the point. The point is everything has a place, except services in ColdBox and I would really like to know why that is the case. CB is modelled after grails, and I am very curious why this convention was never introduced in the first place.

Now I can release my up coming projects, all of which I did ask for people to help on some months ago, but it will not be projects that people can just slot into their projects without some tweaks. And I am not going to change my way, because a small few think it is ok to have all entities, models and services in the one directory.

Sorry but I have been developing long enough, and been around a lot of smart people both in the grails and Java world to see the benefits of the segregation even if others can’t. And like I said if you are working on a small application, you will be fine, work on a larger application and you will struggle with time outs when first running the application with all these in the one directory.

That’s my piece and the reason why, its a damn good reason, now its up to Luis to agree.

And how is it asking for trouble? This application running in CB was performance tested on a server, without making any changes to a stock standard IIS install and we hit the 5000 concurrent users, and made no real indent on it slowing down, falling over. In fact it went from the old application that had to be restarted every 8 hours, to not being restarted in 6 months. It went from a memory footprint of 1.9+g to a little over 600mb max.

The SQL server using ORM doesn’t even batter an eye lid any more. So I ask again how is ORM asking for trouble? I would really like to know where you got your perception on ORM?

9

Oh and to back my case up with some more weight!!

Look into the ColdBox source files and directory structure, if it is good enough for the framework to adopt this pattern, then why is it not good enough for an application running on the framework to have this convention?

Sort of don’t do as I do sort of mentality is it not?

10

Andrew,

I read this thread again about a separation for services. I have to tell you that out of the box I was able to do this by adding the following to my WireBox configuration:

scanLocations=[
“#getAppMapping()#/services”
];

This enabled the services convention, so I could say: getModel(“MyService”) and it will retrieve it from the services folder. Was there something else this convention should do?

11

Yes, as like models and plugins they don’t need to be called models and plugins. In most cases people stick with the default, like handlers but I use controllers instead. If it was by convention, then people can name it what ever ant release a module and it would be able to be just dropped in to any application without any modifications to code.