I have several ViewModels all doing partly the same: del/add/export etc documents. At the moment the code to call these methods lives in the viewmodels. So I have to copy/paste it... When I put that code in a DocumentHelper class I have it only one time, but do you see any reason against calling database methods from a Helper class?
+1
A:
An emphatic YES, you should move your code to a helper class.
I am a strong believer in the Pragmatic Programmer's Don't Repeat Yourself principle. It is one you should strive to follow, as well. By copy-and-pasting the code, it makes making changes an obnoxious pain, since you have to find every single place you copied that code and change it there. The copy-and-paste technique crushes any agility you might have had and makes refactoring a nightmare.
Travis Gockel
2010-10-14 22:02:49
+1 I agree with Travis; but one extra point - just make sure you don't have any View / Model specific code/references in the helpers. I know it's kind of obvious but there's no harm in high-lighting the point.
Adrian K
2010-10-15 00:43:47
Definitely: You cannot make common that which is not common.
Travis Gockel
2010-10-15 01:55:51
@Adrian well I have no this using TBM.Model; in my helper class. Thats a "reference" to my Models, is that bad now? I made the DocHelper a static class.
Lisa
2010-10-15 21:29:36
It's fine if you *use* the model classes in your `DocHelper`, just make sure that you're not storing anything in a `static` variable - have your function use what it provided to it in the arguments and then forget about it. There is probably a CS word for this, but I can't think of it. And to reassure you, making the helper class `static` is the right thing to do.
Travis Gockel
2010-10-15 21:49:11
A:
I wanted to comment supporting Travis G's comment but I ran out of room - hence this 'answer'.
You want to be careful how you arrange your system regarding dependencies; keep in mind how re-usable you want things to be. If the DocHelper references the model then anytime you want to re-use the Dochelper (say in another app) then you will have to bring across the model as well.
Two possible approaches:
Things that are "common" in the context of the model are located in the model assembly.
MyApp.Model // including Model Helpers
MyApp.Common // contains generic helpers
In terms of references, Model could reference Common - but not the other way around.
Things that are "common" in the context of the model are located in a separate assembly - and that assembly is a dedicated Model "helper"; things that are truly generic should be in a separate assembly, e.g:
MyApp.Model
MyApp.ModelHelper // Model helpers are kept separate
MyApp.Common // contains generic helpers
In this case, Model would reference ModelHelper, and Model and/or ModelHelper could reference Common.
Adrian K
2010-10-15 23:26:24
@Adrin "If the DocHelper references the model then anytime you want to re-use the Dochelper (say in another app) then you will have to bring across the model as well." thats is a nice comment, but I do not think I will reuse that code in another application, just another area of the same application.
Lisa
2010-10-16 18:30:50
Wrong way around: the Model can reference the DocHelper (but not the other way around).
Adrian K
2010-10-16 20:01:30