I do not see any reliability coming from the structure, it does not affect how your app responds to failures.
A framework structure does not say anything about your project, what business problem solve, what are its functionalities.
Also the fact that frameworks makes you split a feature in 5 folders like: model, controller, view, css and so on is so wrong. Business logic is what makes us go to work and get paid, and also should be the primary element in a project.
But that is just me, and I know Im in minority on this oppinion.
Well, the point is not about business logic here, it's about code in general. In Rails for example when I see PostsController I surely can expect Post model and views in certain places, moreover I know for most part what exactly will contain those files as well as every Rails developer does. A lot of that stuff is reliable and cuts out a lot of bugs and misunderstanding in developing.
That approach lets you focus exactly on coding important stuff including business logic, not on technical parts and trying to run your app.
Basically Rails works out of the box and you can start to write your app right on the go with reliable and well known approach.
With some other frameworks like React for example you can stuck on the "configure the living hell out of this webpack" step.
I would expect that the Post* anything (model, view etc) should be in the Post folder. If I want to modify a feature I shouldn't not modify 10 folders (orthogonal) in the project, only in 1 place.
The same logic would be applied, You will know where is the Post View, Post Model and so on, .. in the Post folder.
That approach lets you focus exactly on coding important stuff including business logic, not on technical parts and trying to run your app.
It is the exact opposite,
My approach would let you focus on the business logic, and not the framework logic (models folders, views structure etc). You have to know how the framework works, and stick by it.
But hey, all the frameworks are the same in this regard, very wrong in my opinion, and it all started with the misunderstanding of the MVC pattern and Rails.
I would expect that the Post* anything (model, view etc) should be in the Post folder. If I want to modify a feature I shouldn't not modify 10 folders (orthogonal) in the project, only in 1 place.
Oh, this is more of a personal preference I would say. Won't argue with that. That approach may work for someone. I personally wouldn't want to look at a mess inside Post folder where hell know what code you can save. For me Rails way is simpler. I want to edit view - I go to the view folders and look for my REST resource.
Even If I want to extend framework functionality by adding Service Objects for example I just add 'services' folder that continues to work in Rails way among views, models, controllers, etc. folders.
My approach would let you focus on the business logic, and not the framework logic (models folders, views structure etc). You have to know how the framework works, and stick by it.
Yes, you have to learn framework for some time and get used to it. That's a point actually. But after that learning time it brings you benefits like sharing code between other Rails developers and well structured and standardized code base.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I do not see any reliability coming from the structure, it does not affect how your app responds to failures.
A framework structure does not say anything about your project, what business problem solve, what are its functionalities.
Also the fact that frameworks makes you split a feature in 5 folders like: model, controller, view, css and so on is so wrong. Business logic is what makes us go to work and get paid, and also should be the primary element in a project.
But that is just me, and I know Im in minority on this oppinion.
Well, the point is not about business logic here, it's about code in general. In Rails for example when I see PostsController I surely can expect Post model and views in certain places, moreover I know for most part what exactly will contain those files as well as every Rails developer does. A lot of that stuff is reliable and cuts out a lot of bugs and misunderstanding in developing.
That approach lets you focus exactly on coding important stuff including business logic, not on technical parts and trying to run your app.
Basically Rails works out of the box and you can start to write your app right on the go with reliable and well known approach.
With some other frameworks like React for example you can stuck on the "configure the living hell out of this webpack" step.
I would expect that the Post* anything (model, view etc) should be in the Post folder. If I want to modify a feature I shouldn't not modify 10 folders (orthogonal) in the project, only in 1 place.
The same logic would be applied, You will know where is the Post View, Post Model and so on, .. in the Post folder.
It is the exact opposite,
My approach would let you focus on the business logic, and not the framework logic (models folders, views structure etc). You have to know how the framework works, and stick by it.
But hey, all the frameworks are the same in this regard, very wrong in my opinion, and it all started with the misunderstanding of the MVC pattern and Rails.
Oh, this is more of a personal preference I would say. Won't argue with that. That approach may work for someone. I personally wouldn't want to look at a mess inside Post folder where hell know what code you can save. For me Rails way is simpler. I want to edit view - I go to the view folders and look for my REST resource.
Even If I want to extend framework functionality by adding Service Objects for example I just add 'services' folder that continues to work in Rails way among views, models, controllers, etc. folders.
Yes, you have to learn framework for some time and get used to it. That's a point actually. But after that learning time it brings you benefits like sharing code between other Rails developers and well structured and standardized code base.