I have a Rails app and I'm more and more refactoring my app by using value objects, service objects, form objects, etc. Currently, most of them are stored in the "lib" folder of the Rails app, but somehow that feels "far away" from the core app files.
I am wondering what the best practice is for the location these objects in a Rails app?
Refactoring, cleaning-up your models and encapsulating logic in "value objects, service objects, form objects" is a way to go! As for your question about where to store these objects, nothing stops you from creating additional directories under 'app' directory.
By default Rails autoloads these directories, so you don't have to manage these.
Here is an example dir structure of one of my projects, under 'app' directory:
assets
cells
charts
controllers
decorators
form_objects
helpers
help_pages
inputs
mailers
models
modules
queries
renderers
resolvers
services
validators
views
widgets
The above list is by no means a pattern to follow, but I hope the list will inspire your refactoring efforts :)
For me, I created a value_objects directory inside the models folder - just one of the ways to do it.
Related
I want to know what is the best way to order the folders and other components in a vue.js project so that it can be easily maintained and scalable
Like the comments already say there are a lot of ways and opinions of how to structure your vue project.
Like tony19 already said it's a good start to use the vue-cli to generate a project.
If you want to see a real world example of a project you could try this one: https://github.com/gothinkster/vue-realworld-example-app
gothinkster actually has an example of the same project in a lot of different frontends and backends. just look at their repos.
If you plan to use vuetify as your ui library i can also recommand to have a look at their free templates
https://vuetifyjs.com/en/themes/premium/
There are plenty others of course. You might want to search for "vue real world example" or something similar on google.
For scaleability i would say to split things into smaller files and components is a good practice.
For example when creating a vuex module you could have a file for the complete vuex storage or a file for each module or even split each modules into an actions.js, mutations.js getters.js state.js and an index.js which combines those 4.
Please keep in mind that all of the above is my opinion and others might think differently.
I'd advice you to go for the standard cli-structure - but remember that you can still add sub-folders everywhere and don't get caught putting in 200 files under modules or something like that.
If you're about to make a module - add a folder.
If you're about to add a component - add a folder
and so on.
This also counts for the store, which can get pretty big at times.
If you want to split your store because you know it will be too big, add sub-folders for actions, mutations and so on seperately and then add in the files like 'actions/actions_user.vue' '..actions_items.vue' and so on - or leave out the 'actions_' if you're more comfortable with that (they are in the actions folder now anyway, but it could make it harder to search for them if you're not using the file-tree).
For how to split up actions (and the other content of the store) into multiple files, please look up my answer here
there are also the options to add modules in the store or even adding multiple stores, which contributes to scaleability, but - in my opinion - can get finicky and harder to read than it being useful in the end.
It seems that in ASP.NET Core MVC, if I want to use a View Component, I have to put them in Views\Shared\Components\[ViewComponentName], and then name the file "Default.cshtml".
This is rather frustrating, as in the beginning of a large project I am helping to port from Perl CGI, I'm creating a good number of View Components and having five tabs in Visual Studio all named Default.cshtml is confusing.
Is there any way I can avoid this naming convention? Maybe even take them out of their folders so that the file will look like…?
Views\Shared\Components\[ViewComponentName].cshtml
I don't know if there are just some settings I can tweak or what. For the most part, I'm very new to ASP.NET, and still figuring things out. Using ASP.NET Framework instead of ASP.NET Core is an option, though I'd prefer not to, as a lot of the boilerplate is already done.
The documentation on ViewComponents says this:
We recommend you name the view file Default.cshtml and use the Views/Shared/Components/{View Component Name}/{View Name} path.
Which makes me think that there is a way around this restriction, but it doesn't specify how that would work or what it would look like.
Like Nic I agree that having several to dozens of files named default.cshtml is annoying. More so is having several to dozens of folders with just a single file in each folder
Components/ViewComponentName/default.cshtml
Components/AnotherViewComponentName/default.cshtml
Components/AThirdViewComponentName/default.cshtml
et cetera
I understand the reasons for the recommended name and location...but I simply disagree and will accept the consequences. For those who share my cavalier attitude, View() allows you to specify a View name
return View("Schools", items);
or even to specify a path to the View if you put it in a non-standard location
return View("/Pages/Components/Schools.cshtml", items);
I'm using Razor Pages but I'm sure this works for Views/Shared/Components as well.
I'am modernizing a legacy web application, with its frontend based on ExtJS 3.x.
Currently, user interface depends on large file of several thousand lines, with too many nested anonymous functions, encapsulated in an global `Ext.onReady()̀ per file. It's ugly, unreadable and not maintenable.
To maintain code and modernize it, I want gradually refactorize it by :
using namespaces
exploding big files : one class per file (grid, store, form ...)
organizing class files in a good directory structure (app/module/grid|store|...)
loading dynamically class files, when required (maybe with Ext.Loader.load() ?)
optimizing loading by using minifier, as assetic, if possible (in a next step).
All these problematics seems natively solved in ExtJS 4, with its class Loader, its dependency system (require), its Application Singleton and its structure folder conventions...
In ExtJS 3, it seems more confused. So :
What are the best practices in extjs 3 to organize code "like" in extjs 4 ?
Do you have clear examples illustrating these problematics ?
Ext3 is an entirely different beast than 4. Code organization is really up to the developer. I personally would avoid dynamic loading in favor of minification of the entire app. This is what ext4 would give you in a production app. They really only intend dynamic loading for debugging purposes. I have gone the dynamic loading/module route before with Ext3 and it was a regret. It is OK with 4 with it built into the class system.
If you are using a later version of 3, do namespaces with Ext.define. It will do the Ext.ns for you internally and will make upgrading to 4 easier down the path.
You are correct that you shouldn't have big files or config objects, but don't go too overboard. Try to group things into logical classes. A grid can be part of class that contains other components that make sense as a view.
If you do want to upgrade to 4 later, I would recommend trying to emulate the structure a little at least with stores and views. 3 doesn't really impose any structure.
I would avoid dynamic loading with 3. See above.
Definitely minify. Not only will there be much less data going over the wire, but you get huge savings by removing all the overhead of a GET for each script. Gzip might help a little too.
We have been using Yii for building web applications. Once in a while, themes comes to our discussion table.
But, if we have a web application and we wish to change the look and feel only, we may, as well, change the public_html folder, since the structure will be similar.
The only point we see on having themes is for those cases where we may want to dynamically (user choice by clicking on a "change layout button") change the look and feel of an application.
Does anyone uses themes for any other proposes, or configurations?
We use themes to great effect. We operate 6 sites using as single instance of a Yii application. The theme is then selected based on the domain name.
Yes we could have just used 6 different application folders and served them separately. This comes with several advantages though, which you've probably already dismissed if they're not relevant to you, but here they are:
Shared code, updates and maintenance are far easier
Adding a new theme is much cleaner IMO (just a new theme folder rather than a whole application directory)
Global assets, which are then overridden easily in the theme, rather than wiping over them completely, you'r expanding them.
Shared Cache, the whole application caches to a single directory, view cache, data cache etc.
Shared Assets directory, assets are only published once ( although this could in theory be set up in a copied environment)
I much prefer this set up, it looks far cleaner just to override rather than overwrite. Plus really, I can't think of a reason why copying the whole directory would be better than this method, yes there are issues in theming that have to be worked out, but copying the whole source doesn't solve them.
In Java we organize files in packages, Clojure has namespaces and Ruby has modules.
How to organize Objective-C files? any convention/best practice exists?
In Xcode everything is going under "classes" directory.
What I usually do is enforce physical folders (and groups within Xcode) for the files and have them added to the project from where they are. From there you can group files logically however you want them.
By default, it will create the file within the same Classes folder, and I find it difficult to navigate when dealing with an external source control client.
Leverage Categories to have separate files for separate logic for a particular class. For example I will have private method interface in the implementation file with a separate category name so that it is somewhat "private" to other implementations.
For uniqueness, you could try to prefix folders or groups of classes.
We use MVC on all but the smallest projects. So in the "Classes" folder we start by adding three folders, Model, View, and Controller. Under those directories we might create subfolders grouped by functionality with the app (controllers for various subsections, etc.). You can add files directly to Xcode or the folders themselves. Similarly we have a Resources directory, usually in the same directory as the .xcodeproj file and under that folders for Images, Nibs, Audio, etc.
Of course the above just describes a disk-based organization strategy. Since Objective-C is still C, you can build libraries and header files for APIs that you want to export. You can also use categories. Many of our projects reference a /Common directory that is outside of the project folder (and under Common we have Model, View, Controller, etc.). Sometimes we copy files from Common into the project if we expect to make significant changes to them that we don't want other projects to inherit.
I just organize things in XCode. Group files as appropriate. Yes, everything ends up in the Classes directory.