I'm pretty new to MvvmCross and understand that successful use of the framework relies on specific naming conventions in some areas. I have been looking around trying to find information on these naming conventions, but apart from figuring some of them out from watching various videos, I haven't been able to find anything that explains all the requirements in one place. Any suggestions?
The naming conventions used:
in bindings are in https://github.com/MvvmCross/MvvmCross/wiki/Customising-using-App-and-Setup#registering-custom-bindings
in View-ViewModel lookup are in https://github.com/MvvmCross/MvvmCross/wiki/Customising-using-App-and-Setup#overriding-view-viewmodel-associations
the default IoC setup - using the postfix "Service" is described in https://github.com/MvvmCross/MvvmCross/wiki/Service-Location-and-Inversion-of-Control#bulk-registration-by-convention
the registration of ValueConverters is described in https://github.com/MvvmCross/MvvmCross/wiki/Value-Converters#referencing-value-converters-in-touch-and-droid
The MvvmCross manifesto - https://github.com/MvvmCross/MvvmCross/wiki/The-MvvmCross-Manifesto - doesn't force any of these conventions on you - you can override this and use your own convention schemes or use your a different mechanism for anything you want to do.
Related
I have a mild case of analysis paralysis when it comes to naming.
Suppose we are wrapping some google API. These all seem reasonable:
googleClient
googleDriver
googleActor
googleAdapter
googleBroker
Actor might be more suited to a more concurrent program. But then google API is inherently asynchronous so maybe a good fit.
Suppose the API supports websockets or push messages and it supports methods like .subscribeToEventA(... it might make sense to call it
googleEmitter
googlePubSub
googleEventBus
or even
googleWrapper
The issue being they all seem reasonable and I have no rule of thumb for choosing between them. Is there a general style guide to lean on or a rule of thumb? Maybe some authoritative glossary for terms like these?
Naming things is subjective and so there is no right or wrong answer to what something should be named.
However you can name things based on well established design patterns so readers are more likely to be knowledgeable as to why something is named as it is.
Also key to naming things is to try to be consistent. Once you have settled on a name for a type of entity it's a good idea to add it to a Domain Specific Language (DSL). Having a documented vocabulary for your domain then makes it easier for other authors to use consistent naming conventions in your environment.
Suppose I have written a library in a programming language (e.g. Java) to interact with an external component (e.g. a database).
I would now like the community to provide implementations in other languages.
How can I enable and encourage, other developers to provide implementations that are identical in functionality to mine.
Some examples may be:
Provide a written specification of behaviour
Provide a reference implementation
Provide a testing framework so they can validate their implementation (can this be done across multiple languages?)
What other options are available?
Common approach of all that you are after for, can be the abstraction level of Coding conventions. Since they are set of guidelines for a programming languages that recommend programming style, practices and methods for each aspect of a piece program written. These conventions usually cover file organization,indentation, comments, declarations,statements, white space, naming conventions, programming practices,programming principles, programming rules of thumb, architectural best practices, etc.
About
enable and encourage, other developers to provide implementations that are identical in functionality to mine.
you can use Interfaces (protocols). Even if they are used to define an abstract type that contains no data or code, they also define behaviors as method signatures.
Your examples are good. But in addition to
Provide a testing framework so they can validate their implementation
you can introduce the main ideas of the Test-driven development:
Establishing the goals of different stakeholders required for a vision to be implemented
Drawing out features which will achieve those goals using feature injection
The goal of developer TDD is to specify a detailed, executable design for your solution
read more
As i grow in my professional career i consider naming conventions very important. I noticed that people throw around controller, LibraryController, service, LibraryService, and provider, LibraryProvider and use them somewhat interchangeable. Is there any specific reasoning to use one vs the other?
If there are websites that have more concrete definitions that would be great.
In Java Spring, Spring Boot and also .NET you would have:
Repository: persist data in the database and perform SQL queries.
Service: contain most of the business logic
Controller: define REST endpoints, which contains as little logic as possible.
Conceptually this means that the WHAT (functional) is separated from the HOW (technical) as much as possible. The services try to stay technologically neutral. By contrast a controller only wants to define an external contract for communication. And finally the repository only wants to facilitate the access to the database.
Organizing your code in this way keeps the business logic short, clean and maintainable. Unfortunately it is not always easy to keep them separated. e.g. It is tempting to pollute or enrich your objects with meta-data in the form of decorators/annotations. (e.g. database column name and data type).
Some developers don't see harm in this and get away with it. Others keep their objects strictly separated and define multiple sets of objects.
The objects for the database are often referred to as "entities" or "models".
For a REST controller they are often referred to as DTOs which stands for data-transfer-object.
Having multiple objects means that you need Mappers to convert one type of object to another. Some frameworks can do this for you (e.g. MapStruct).
It would be easy to claim that strictness is always a good thing, but it can slow you down. It's okay to strike a balance.
In Node.js, the concepts of controllers and services are identical. However the term Repository isn't used very often. Instead, they would call that a Provider or sometimes they would just generalize Repositories as a kind of Service.
NestJS has stronger opinions about this (which can be a good thing). The naming conventions of NestJS (a Node.js framework) are strongly influenced by the naming conventions of Angular, which is of course a totally different kind of framework (front-end).
(For completeness, in Angular, a Provider is actually just something that can be injected as a dependency. Most providers are Services, but not necessarily. (It could be a Guard or even a Module. A Module would be more like a set of tools/driver or a connector.)
PS: Anyway, the usage of the term Module is a bit confusing because there also are "ES6 modules", which is a totally different thing.)
ES6 and more modern version of javascript (including typescript) are extremely powerful when it comes to (de)constructing objects. And that makes mappers unnecessary.
Having said that, most Node.js and Angular developers prefer to use typescript these days, which has more features than java or C# when it comes to defining types.
So, all these frameworks are influencing each other. And they pretty much all agree on what a Controller and a Service is. It's mostly the Repository and Provider words that have different meanings. It really is just a matter of conventions. If your framework has a convention, then stick to that. If there isn't one, then pick one yourself.
These terms can be synonymous with each other depending on context, which is why each framework or language creator is free to explicitly declare them as they see fit... think function/method/procedure or process/service, all pretty much the same thing but slight differences in different contexts.
Just going off formal English definitions:
Provider: a person or thing that provides something.
i.e. the provider does a service by controlling some process.
Service: the action of helping or doing work for someone.
i.e. the service is provided by controlling some work process.
Controller: a person or thing that directs or regulates something.
i.e. the controller directs something to provide a service.
These definitions are just listed to the explain how the developer looks at common English meanings when defining the terminology of a framework or language; it's not always one for one and the similarity in terminology actually provides the developer with a means of naming things that are very very similar but still are slightly different.
So for example, lets take AngularJS. Here the developers decided to use the term Controller to imply "HTML Controller", a Service to imply something like a "Quasi Class" since they are instantiated with the New keyword and a Provider is really a super-set of Service and Factory which is also similar. You could really program any application using any of them and really wouldn't lose anything much; though one might be a little better than another in certain context, I don't personally believe its worth the extra confusion... essentially they are all providers. The Angular people could have just defined factory, provider and service as a single term "provider" and then passed in modifiers for things like "static" and "void" like most languages and the exact same functionality could have been provided; this would have been my preference, however I've learned not to fight the conventions and terminology of the frameworks your working no matter how strongly you disagree.
Looking myself too for a more meaningful name than Provider :)
And found this useful post
Old dev here that stumbled on this. My opinion and how I’ve seen it used over the last 20 years shows that it varies by language but the Java C# crowd mostly uses them as follows.
A service handles business logic and deals with domain objects. You find services in controllers and other services.
A repository does NOT handle business logic, but instead acts like a pool of domain objects (with helper methods for finding or persisting them. Services often contain repositories. Repositories often contain a context and are responsible for mapping from infrastructure shaped data to domain shaped data if the definitions have drifted apart. Controllers also often contain repositories for crud endpoints.
A context handles infrastructure the domain owns. Most often this is a database, but context means that anything that touches this data does so through (in) this context. A context returns infrastructure shaped data. A repository often contains a context. Context directly in services is sometimes appropriate. Context in controller is a hard no.
A provider provides access to infrastructure some other app owns. Most often these are rest apis, but can also be kafka streams or rpc classes that read data from or push data to someone else. If the source of truth for some of your domain objects fields changes you will probably see a provider next to a context in your repository, and your repository handles insulating the rest of your code from that change. Providers that provide rpc functionality are often found in services. In micro services or gateways or vertical slice architecture you sometimes see providers directly in controllers.
One old guy’s opinion but I hope it helps.
Why controllers are named "users_controller.rb" and models are not named "user_model.rb"?
Why there is "application_controller.rb" but inside views the folder "layout" is not named "application"?
Code flows from thought best when the naming supports the developers internal model of the problem. When building an application, I don't think of finding a user model (UserModel.find) I think of finding a user (User.find). On the other hand, the controllers are the translation layer between the web interface and the data store (and business logic), so it makes more sense to call them something different.
There's also the problem of namespacing; if both my model and controller are named User, then which User am I referring to at any given moment? In this case, either you name everything with their type, which runs into the problem I describe above, or one 'wins' and is allowed to be referenced 'bare'. It seems to make the most sense that the model would win, so as to provide a better mental mapping.
Inside app/views/layout is application.html.erb and you can have other layouts which are selected by different controllers.
In the end, however, these were choices made during the development of Rails, and they are entirely stylistic choices based on what the developers thought made the most sense, so there isn't really a 'right' answer to your question, unfortunately. In fact, some similar decisions have been revisited. (application_controller.rb used to just be named application.rb.)
Ruby on Rails follows "Convention over configuration" principle. Particularly naming conventions are extensively used by Rails while mapping your routes to controllers, auto-loading and reloading classes, finding appropriate template for an action and many other features.
That principle leads to some restrictions as you can't easily break some of the conventions without getting into troubles. But on the other hand it makes our lives easier as we get smaller amount of configuration and can easily move from one Rails project to the other because all of them have similar structure and follow same conventions. In addition, I believe, that makes Rails core development much easier as core team have a lot of information about how the project using Rails will be structured and they don't have to worry that much about generalization. They simply assume you play by the rules and follow conventions.
Though, I doubt many of naming conventions have serious reasoning behind them. I think at some point someone just decided that it'd be easier for Rails to handle your controllers and distinguish them from other classes if they all have Controller suffix. And here we are having all our controllers in app/controllers directory with that suffix.
We are deciding if we should standardize on camelCase or PascalCase for XAML resource names.
Does anybody know if one style is usually favored over the other?
Does Microsoft have any convention for this?
For the record, we use camelCase for fields (that includes WPF controls, in the very few cases where they are named)
To avoid religious arguments: I'm not looking for "this approach is BETTER than the other because..." responses. A good answer would include links to reference material and/or statistics.
For the x:Name attribute, you should use camel casing, as this generally results in a field being created behind the scenes. Microsoft, doesn't really follow this though in their default Styles, as control templates are one exception where a backing field is not created.
For the x:Key attribute, I've only ever seen pascal casing used. This includes in Microsoft's default Styles.