This might be a bit of a noob question, but I'm curious why the convention for MVC classes is to be in their own namespace, eg
namespace WebApplication1.Controllers
and not
namespace WebApplication1
Is there a good syntactical reason for this or is it just to improve readability?.
Is it perfectly ok to not follow this convention and use the same namespace for the whole project?
You can use namespaces any way you like, as long as it makes sense to you.
What they've done there is simply a convention deriving from the separation of concerns part.
Are their disadvantages to this method? Well yes, separate too much and your classes become a mess with too many using statements.
If you put too much under one namespace that can also cause issues because you don't know exactly what's available to you and it makes finding anything difficult.
If your namespaces follow your folder structure then it can help keep your code nicely organised and everything is easy to find just by looking at the namespace.
It is possible, but namespace are there for minimizing classes name conflicts, which if you handling middle+ projects you will encounter.
More on Namespaces
They also help the Intellisense display current available entities, but this is just a bonus and not the actual target of name spacing.
Related
Is it a good practice to namespace jobs?
In my application I have two jobs that are related to the Page model - both of them are going to receive a post_id and perform a specific task there. The jobs are called PageWritingScoreJob and PageArchitectureScrapingJob. I want to use the namespace Page instead: Page::WritingScoreJob and Page::ArchitectureScrapingJob, but not sure if that's a bad practice.
thanks
There is no real reason why using namespaces would be a bad practice.
In Rails apps everything is generally lumped in the global namespace not necessarily because it's the best way to do it - it just convenient.
It's a widely accepted that placing code in the global namespace is problematic when it comes to interoperability as it greatly increases the risk of name collisions. This is especially true in Ruby which lacks a import system like that in Python or Ecmascript. That's why almost every gem incapsulates it's constants in a module.
In a rails app though you are most often the end consumer of the application code which means that placing your controllers and models in the global namespace works well enough that it's often worth the trade-off of simpler code templates and not having your code intended an additional step and nested in an additional folder.
Just a quick question that strangely I can't find anywhere (maybe I'm wording the question wrong when I ask google)... I have some shared functionality across a few models, but not shared in any way that I'd want to make an actual class to extend, just small utility methods that I'd like to mix in. Where is the "best practice" place to put these kinds of modules?
I can put them in ./lib, but that feel wrong for some reason, I'm not sure. Where's the typical place to put this stuff?
Edit: I see why ./lib felt wrong now. I didn't realize that in rails 3 it no longer autoloads ./lib by default, so I though this had moved elsewhere. Which I guess it has in the sense that it's now up to you. Thanks!
We try to "name" these kinds of things and put them somewhere as appropriate. For example, "concern" is a common name for mixins that provide a specific functionality as a module mixin, so we put them in app/concerns. (In fact, I believe this is a default folder in Rails 4). You may need to adjust your autoload path appropriately.
./lib is an appropriate place. You could namespace these similar modules together, under say, ./lib/active_record_mixins/
There is no "best" place, at least as you describe your mixin.
It was always up to you; you can add whatever you want to your list of autoloads.
I don't see why lib doesn't "feel right", it's as good as any other. Some types of mixins have names, like "concerns" and "decorators", but it's not clear if what you're mixing in falls into that broad a category.
Autoloading of everything under lib was turned off to control autoloading, not because it wasn't an okay place to put libraries. For modules that don't fit into a broad, app-wide category (think "decorators" or "concerns") lib seems perfectly reasonable.
Autoloading means you have to use require instead of everything being loaded everywhere; this isn't necessarily a Bad Thing, IMO.
Because it depends entirely on the nature of the code, the structure of your app, and how you want to structure your app, I'm not convinced there's an open-ended "best" practice.
What are the guidelines about when it is better to nest Model name spaces and when it is better to leave them all top-level?
For instance, when I have a few classes that all have something to do with one core class (and the majority of the system only deals with that core class) then my instinct tells me to declare them as such:
CoreModel
CoreModel::DependentOne
CoreModel::AnotherDependent
Almost always this corresponding to has_many/belongs_to relationships (i'd almost consider this the next candidate for convention over configuration.)
And again, my routes often reflect this nesting:
/CoreModels/:core_model_id/DependentOne/:id
The reason I feel like I should do this is because often two component areas of the same large application may need a supporting component with similar if not identical names as other areas of the software. I feel like name spacing these dependent models (which only exist to support that core model) is the best way to go.
I'm confused because while some times doing things this way can make stuff easier (such as link_to which needs only to take the DependentOne model and will automatically route correctly) yet other items such as form_for refuse to work properly (because it doesn't route properly and if I add the CoreModel to the form_for it complains about no such route core_model_core_model_dependent_one etc....
Perhaps I haven't been clear enough and so I'll ensure I update this as requests for clarifications come in.
...the majority of the system only deals with that core class...
In that case, I wouldn't bother namespacing them.
The reason I feel like I should do this is because often two component areas of the same large application may need a supporting component with similar if not identical names as other areas of the software. I feel like name spacing these dependent models (which only exist to support that core model) is the best way to go.
Bingo - if you have name conflicts, namespacing is a good way to fix it. But, do you have that problem yet?
Namespacing prevents name conflicts, but in Rails it also introduces some gotchas and headaches and (throughout the app) quite a bit more typing. So, to me, it isn't worth it unless you actually have a name conflict.
Consider a structure like this, with your core model and many that just help it.
#Core Models
Model
Supporter
Assister
Helper
Benefactor
For most of the life of your app you may never run into a problem. If you do finally hit one, you could just do this:
AltModel
AltModel::Supporter
OtherModel
OtherModel::Benefactor
Or if it's really simple just prefixing the class name would work:
AltModelSupporter
OtherModelBenefactor
For that matter, it's probably simpler to name your core models in this way than it would be to "properly" namespace them:
CoreModel
CoreSupporter
CoreAssister
So, there are many ways to accomplish what you need, none of which suggest you should bother namespacing the core functionality of your app when you don't actually have a namespace conflict. Given the headaches you've already run into I think you'll be happier leaving the core models of your app in the top-level namespace and only nesting alternate models that actually have a conflict down the road.
I'm starting to work with StructureMap on a windows application project. In working on learning the basics, I found 2 ways to arrange my solution that accomplish the same goal, and I'm wondering if anyone can comment on if one of these 2 seems like a better option, and why.
The goal here was to use IOC so that I could use 2 services without taking dependencies on them. So I I created interfaces in my Business Layer, and then implemented those interfaces in my Infrastructure project and wrapped the actual services at that point.
In my fist attempt at this, I created a project DependencyResolver, which has code to intialize structuremap using the fluent interface (when someone wants IServiceA, give them an instance of ServiceX). Because the initialization of DependencyResolver needed to be kicked off from my app, I have a reference from the app to DependencyResolver like this:
So then I found that I could remove my reference to DependencyResolver, and rely on StructureMap scanner and naming conventions to get that reference at runtime, so then my setup looks like this:
So then, I took the naming conventions further, down into the services I was using, and was able to do away with the DependencyResolver all together. At this point, I am totally relying on the structuremap scanner and naming conventions to get things setup correctly:
So. Here I am, not quite sure how I should feel about these 3 options. Option 1 seems good, except I'm left with the UI indirectly referencing all the things that it shouldn't be referencing (directly) because of the use of StructureMap. However, I'm not sure if this really matters.
Option 2 removes the need for a reference from the app to DependencyResolver, and relies on naming conventions to access classes in that project, and I still have a high level of control over all the remaining setup (but I have now taken a dependence on structureMap directly from my application).
Option 3 seems the easiest (just name everything a certain way, and scan your assemblies), but that also seems more error prone, and brittle. Especially if I wanted to do something a little more complex than IServiceAbc => ServiceAbc.
So, can anyone who has a lot more experience with this stuff that I do give me some advice?
Should I be avoiding the indirect references from my App to my services, and if so, what are the real benefits of doing that?
Am I right that trying to do everything with naming conventions is only wise on simple projects?
Is there a standard pattern for doing what I'm trying to do here?
Sorry for the long post..
Encapsulate all usage of StructureMap in a Composition Root and use Constructor Injection throughout the rest of your code base.
You can implement the Composition Root in a separate assembly if you'd like, but I usually prefer placing it directly in the executable itself, and then implement all of the application logic in separate libraries.
I have used the top design on projects and it work extremely well.
Dependency resolvers are more or less factories to return interface instances, isn't structure map just one way to implement this? In that case I would make request for any item via the dependency resolver at one central place. Then it is also possible to remove structure map and add another service locator (unity, castle windsor etc.) in without changing anything else about your app.
Dependencies should not be resolved from two places as seen in your second option, and not only via the UI project in the third option (what happens if you swap out your UI project and put a different one in then?).
I have got a project with about 50 controllers and 60 models.
It is quite difficult to work in that mess.
How can I improve that scructure?
Now I am creating namespaces for some logical parts of my application and store them in separate folders. But for models this have got some side effects.
You can organize your classes in subfolders - you don't even need to structure them into submodules (but you can if you want to).
See this other question for details.
Refactoring is a discipline that deals with that kind of problem.
Consider this book.
you can refactor your code using namespace.