which of the following syntax is considered best practice?
For<IMyInterface>().LifecycleIs(new HybridLifecycle()).Use<MyImplementation>();
For<IMyInterface>().LifecycleIs(Lifecycles.GetLifecycle(InstanceScope.Hybrid)).Use<MyImplementation>();
if the first one is correct, can I create one object HybridLifecycle, and use it for multiple For<...> statements, or is it necessary for each For<> to create a new HybridLifecycle?
Using the configuration helpers is probably the best practice.
For<IMyInterface>().HybridHttpOrThreadLocalScoped().Use<MyImplementation>()
Related
I am new to Microsoft ASP.NET MVC framework. I am working on MVC project where I have a controller. It has various ActionResult methods. Also, it needs several helper functions. Can I write them in controller itself? Please guide me.
No, it's not best practice.As helper function needs to be define/implemented in static class. So it is better to to have standalone seprate helper class.
The answer is: it depends. First of all it is not clear what do you mean with helper functions.
if you are talking about ASP.NET MVC HTML Helpers, it is better to move them to separate class. Tutorial how to create and use them.
if you are talking about general helper functions that evaluate something, of course you may leave them in controller, move to the base controller or move to separate class or library (depeneds on context). You may check implementation of standard System.Web.Mvc.Controller, there are a lot of methods and properties in it.
I think there's no specific rule regarding this.
IF
you're going to reuse the helper function, abstract/separate it to another class.
ELSE
put it in the same class for better code cohesion and readability.
I wish to replace the implementation of System.Web.Mvc.ActionMethodSelector as used by the FindAction method of ReflectedControllerDescriptor, but would like to take advantage of the existing implementation, ideally by deriving from ActionMethodSelector. However, because the class is marked as internal the only way I can see to do this 'properly' is to derive from ReflectedControllerDescriptor and implement FindAction by copying the code from ActionMethodSelector. I wish to avoid this however due to the quantity of code, and potential issues trying to keep it up to date with the framework.
I'm considering the following approaches:
Biting the bullet and copying the code
Using reflection so as to take advantage of the existing implementation
Are there any other approaches that I'm missing, better or otherwise?
I know it is a bit late to answer still I am giving it a try.... :)
I believe that you somehow want to tweak action method selection process in ASP.NET MVC. If my understanding is correct you can make use of custom ActionMethodSelectorAttribute by deriving from System.Web.Mvc.ActionMethodSelectorAttribute. Write your own custom logic in the custom selector and apply it on the top of the action methods. I believe in this way the action method selection process can be tweaked without disturbing the natural process.
If you wish you can visit these links: http://programersnotebook.blogspot.in/2014/02/aspnet-mvc-actionnameselector-and.html, http://programersnotebook.blogspot.in/2014/02/aspnet-mvc-actionnameselector-and_2.html
I'm new to Jena, but when I look at the vocabularies defined with the Jena source (i.e. in directory: jena-2.10.0-Source\jena-core\src\main\java\com\hp\hpl\jena\vocabulary) I see some of the vocabularies create properties and resources using 'ResourceFactory.createProperty()' (e.g. OWL2.java, RDF.java, RDFS.java), whereas others in the same directory use 'ModelFactory.createDefaultModel().createProperty()' (e.g. DC_11.java, VCARD.java, DCTerms.java).
I understand that ResourceFactory is used to create resources and properties without reference to a 'model', but I just want to understand why some of these vocabs choose to create and use a 'model' instance while others choose not to.
Is it just personal style, or is one approach generally recommended over the other (maybe one style is an 'old approach', as I understand Jena has been around a long time)?
I'd like to use both the RDFS and DC_11 vocabs with my code, and obviously define my own app-specific resources and properties, so I'm just trying to understand which approach I should adopt for my own stuff.
That both styles are used is just historical accident. I think these days, I'd probably suggest using the ResourceFactory approach, simply because it avoids the (small) overhead of allocating a model, and the model gives you no real advantages. At some point, we'll probably go back and do some refactoring to just use a single approach in the Jena codebase.
I don't like the idea that in Rails models are used both for business logic and persistance. I'd love to separate the two: have my models contain business logic, and use another class hierarchy to persist.
Has anyone tried this and gotten any traction? Off the top of my head it seems like it goes too strongly against Rails: form_for requires an ActiveModel object to work, as do many common plugins that work directly on business objects.
Any thoughts?
I think it's going to be hard/annoying to do it exactly as you state, but there are some good ways to separate out your code.
One way to do it would be to, just as you said, have 2 separate classes, one for persistence and one for business logic. Let's call them Foo and FooBL. Foo would inherit from ActiveRecord, contain validation logic, and some simple methods for querying and manipulating the data. FooBL would be a regular ruby class that would use the Foo class as needed. You could even use some of Ruby's Delegation features so some of the attributes and methods of Foo could be used directly.
Another slightly different way is to use Presenters, like in the Draper gem. Rather than breaking off the business logic from the the persistence logic, it breaks off the view-related logic. Not exactly what you're looking for, but it still helps in cleaning up your code.
I would also recommend that you take a look at Avdi Grimm's book, Object on Rails. He takes a deep look at some of these patterns and practices.
Good luck!
Simple question about best-practice. I'm using Kohana... is it okay to use helpers in views? For example, to use URL::site(). I could pass it from controller, you know. I assume it's okay, because there are helpers like HTML that is meant to be used in views, right?
The way you're currently doing it is ok, altough the whole practice of having any logics in views is questionable, but it's how Kohana is currently recommending.
When you get to use ViewModel pattern (with Kostache?), you'll separate all logics from templates. Until then, it's ok to use methods that don't do anything that should be done in the controller / model (echo, conditions and loops are "considered allowed").