Is It a Bad Idea Do Divide the Models into Directories

Is it a bad idea do divide the models into directories?

No, it's not a bad idea. Many people do it and I couldn't live without it in large applications.

There are two ways of doing it:

The first is to just move your models. You will, however, have to tell Rails to load the wayward models (as it won't know where they are). Something like this should do the trick:

# In config/application.rb
module YourApp
  class Application < Rails::Application
    # Other config options

    config.autoload_paths << Dir["#{Rails.root}/app/models/*"]
  end
end

The first way is easy, but is not really the best way. The second way involves namespacing your models with groups they're in. This means that instead of having User and UserGroup and UserPermissions, you have User, User::Group and User::Permission.

To use this, generate a model like this: rails generate model User::Group. Rails will automatically create all of the folders for you. An added benefit is that with this approach, you won't have to spell out the full model name for associations within a namespace:

class User < ActiveRecord::Base
  belongs_to :group # Rails will detect User::Group as it's in the same namespace
end

class User::Group < ActiveRecord::Base
  has_many :users
end

You can specify however many levels of namespacing as you want, so User::Group::Permission would be possible.

Should I stop fighting Visual Studio's default namespace naming convention?

Same as you - I fought this for the longest time. Then I started considering why I created folders. I found myself starting to create folders to represent namespaces and packages instead of arbitrary buckets.

For instance, in an MVVM project, it might be helpful to put views and view models in a separate namespace. MVC will have a separate namespace for Models, Controllers, and Views. It is also beneficial to group classes by their feature.

Suddenly, the project feels more organized. It is easier for other developers to find where features are implemented.

If you standardize on your namespace practices, all of your projects will have the same predictable structure which will be a big win for maintenance.

Reasons for not having a compact structure of an MVC application?

It all depends on what you want to achieve, and what your workflow is. You seem to be working in PHP - it's worth looking at non-PHP frameworks like Ruby on Rails.

Typically, you want an output folder to be "read-only" - the developer should not manually edit files, instead the build and deploy pipelines run tools like Gradle to convert SASS/LESS and JS files (from the /source folder) into CSS and minified/concatenated Javascript and place them in the correct location in /public. The build and deploy pipelines often have different configs for development and production builds (minifying only for production, for instance).

In Ruby on Rails, the structure is mostly as you describe as "much better" - except that "templates" is a folder underneath "views" called "layouts". There's a build step (which runs automagically) which converts the various asset files (SASS/LESS, JS etc.).

You can see a detailed description of the Ruby on Rails directory structure here. Django's directory structure is explained here.

Answering the questions in your comments:

• Where should the SASS/LESS/JS/Coffee script files go? - Up to you. In Rails, they live in /app/assets/javascripts and /app/assets/stylesheets; in these folders, there is one file for each view, as well as application-level files. This makes your build process nice and simple - you have just 2 folders to worry about, and don't have to modify your build every time you create a new view.
• How do I structure my views - I have application-level views and specific page views. Again - mostly a question of convenience. In Rails, all the templates - live under /app/views. Application-level views live in a folder called /app/views/layouts - they are really not that different to the page-level templates, so moving them out of that folder doesn't seem to achieve very much, whereas keeping everything in the same top level folder makes build and configuration simpler.

So, no, there's no reason to do what you suggest.

Divide data into multiple hashes on the basis of timestamp

Order notifications by timestamp, add a column to select what wil have date only and then use group_by in Ruby. That should be the easiest way to have it.

For selecting additional column to work you should add attr_accessor for it.

http://www.ruby-doc.org/core-2.0/Enumerable.html#method-i-group_by

How do I layout my C++ program? (where should I put the .h and .cpp files?)

The following is fairly typical...

third-party library
  release
    obj
  debug
    obj
  include
  src
    sublib 1
    sublib 2

mylibrary
  release
    obj
  debug
    obj
  include
  src
    sublib 1
    sublib 2

myapp
  release
    obj
  debug
    obj
  subapp 1
  subapp 2

mylittleapp
  release
    obj
  debug
    obj

Basically, subfolders for subprojects is common for larger projects, but mostly a particular project has folders for src, include etc. A folder for each build configuration is common, and keeping the obj files and other intermediates in a subfolder of that is a good idea. It may be tempting to put subproject folders in obj folders, but usually that's unnecessary - the obj folders don't need to be well organised, so the only concern is a filename conflict, and the best fix for that is to have unique source filenames within (at least) each project.

The "include" folders should IMO only contain headers that will be #included by other projects - internal headers belong in the "src" folder.

Putting UI stuff in a separate folder isn't a bad idea, if it's big enough. I've seen UI stuff done as a separate static-linked top-level project, and I do mean app-specific here, not (e.g.) wxWidgets. Usually, though, that level of division is sub-project if it's worth separating at all. How you divide subprojects is more a matter of application-specific blocks in general, so it depends on whether UI stuff is best handled as a separate block or as separate chunks mixed in with task-specific logic.

Namespaces aren't the most used language feature, possibly because a lot of people use "using" so much they don't make much difference. A namespace for a main library project makes sense, but associating subfolders to namespaces 1:1 isn't something I've seen. I personally have a namespace that encompasses most of my library code, with a couple of sub-namespaces for things rarely used in general, but used a lot in a few places (e.g. a "bitwise" namespaces). The sub-namespaces are limited to single source/header pairs, so no need for subfolders. Most of the library-specific selection is done by including the right header - except that I usually include the lot through a main-project top-level header anyway.

Basically, namespaces are a way of avoiding naming conflicts. They don't necessarily associate with abstractions or functional blocks or anything. Within a particular project, you're probably better off just making sure the names don't conflict. As with the "std" namespace, it's fine to put a lot of stuff in one namespace.

As you say, though, this isn't a definitive answer - there are of course minor variations and quite different approaches.

One app with many models vs. many apps with single model

Is it better to have one model per
Django-app?

One of the key ideas for a reusable application is: Do one thing, and do it well

If an app needs several models (PostEntry, PostAuthor in case of a Blog App) this is by no means bad. Tags, Categories, Comments however represent distinct features which ideally can be reused in another context and therefore should be distributed as standalone apps.

Is there best practices?

To get a feeling for a good app organization I'd first take look at Django Reusable App Conventions.

Then you are ready for James Bennett's talk about Resuable Apps from DjangoCon 2008 (Slides). Another, more recent take on the same subject is Pluggable Django Application Patterns from PyCon 2011

Splitting app's parts in their own assemblies when using Prism

First of all, module is not equal assembly. You can spread a module's parts between several assemblies (including Models, Views and ViewModels). Although, usually you place classes related to a module together in one DLL or XAP file (in case of Silverlight if your module is a separated Silverlight application).

As of your case, if a Model is a shared entity which can be used by several modules, Prism encourages to place it in so called Infrastructure assembly that keeps shared non-module specific logic. Otherwise, it could be a good idea to place MVVM parts together, since they solve common business tasks. In the future, if you need to replace implementation of one of the MVVM's parts, you can do it just adding a new one and adjusting container's mapping.

Laravel 5 keep views and models in separate folder in resources views directory

You have complete freedom on the structure of your application. If your view is

resources/views/admin/mycontroller/index.blade.php

and your controller is placed into the app/Http/Controllers/Admin/MyController.php file, then you can use the view this way:

namespace App\Http\Controllers\Admin;

use App\Http\Controllers\Controller;

class MyController extends Controller {
    public function index() {
        return view('admin.controller.index');
    }
}

Concerning your models, again Laravel is flexible and uses the PSR-4 autoloading, so your namespace structure must match the directory structure. If you want to place your Users model in the App\Models\Admin namespace, then simply create this folder structure:

app/
    Models/
        Admin/
            Users.php
...
resources/
vendor/

In the Users.php file, put your model class:

<?php
namespace App\Models\Admin;

use Illuminate\Database\Eloquent\Model;

class Users extends Model
{
    // ...
}

Note that the namespace of Users matches the directory structure:

• App is mapped to the app/ directory
• App\Models is mapped to app/Models
• App\Models\Admin is mapped to app/Models/Admin
• and finally App\Models\Admin\Users is mapped to app/Models/Admin/Users.php

If your Users class is intended to replace the standard Laravel User Eloquent model, then you also have to change the config/auth.php config file and replace the line

'model' => 'App\User',

with

'model' => 'App\Models\Admin\Users',

I hope this helped.

---

Related Topics