views:

38

answers:

4

I know this topic has been discussed to death, but there is one thing that I can't wrap my head around.

I'm working on a Web Application using ASP.NET MVC and I come across a scenario where I need a helper class (this usually happens in the early stages of development. So I go ahead and create a helper project in my solution that I use to manage all of my Helper Classes.

Now, do I have to build that project and dump the dll in the bin directory every time I make changes to is, or is there a way to have the main web application reference the classes contained within the separate project without the separate build process?

I'm just looking for the easiest way to add helper classes without the hastel of building and moving the dll every time I make a change or addition.

Also, sorry for the very newbie-esque question here. All of the web apps I've build in the past have all been in the same project (web forms, App_Code, etc).

+3  A: 

You can encorporate your Helper project and your MVC project in one Solution. From your solution explorer simply right click on the SolutionName and choose add existing project. This will allow you to add an existing project as part of a whole solution. When finished then you can add references to your projects by using other projects in your solution. No dll copies needed just build the solution and your ready to go.

John Hartsock
This is great, thanks. Evidently I can't accept your answer for another 9 minutes... lol
rockinthesixstring
+3  A: 

You should be able to reference a sibling project within a single solution in Visual Studio -- assuming you're using Visual Studio. Try right clicking on References, and selecting "Add Project Reference".

If you're not using Visual Studio, setting up your build automation tool to copy a freshly compiled DLL out to a number of target locations is one of the most common operations in terms of build automation.

Jomdom
+1  A: 

You'll just create another project in the same solution as your web app. In the web app, right-click References and choose Add a Reference...

Then you'll see a tab labelled Projects. Choose the project that you created for your classes. The dll copying (if necessary) will happen automatically on every (solution) build.

That said, I prefer to keep HTML helpers right within the web app. They are dependent upon MVC, and I don't think class libraries should be dependent upon the "web" side of things. But that's just a preference.

(I usually put data and model stuff in a separate project.)

Matt Sherman
Thanks for that. Note, I'm not referring to HTML Helpers but rather generic helpers like `GetUserData`, `SendEmail`, etc.
rockinthesixstring
Cool. If these helpers are shared across solutions, you might consider creating a /lib folder in your solution folder which will hold those "third-party" dll's. If you add a reference to them, VS sees it as a relative link, so the dll's will travel well. But then, yes, every time you modify one of the external dll's you'd need to copy it over to /lib -- but you wouldn't need to add a new reference.
Matt Sherman
+2  A: 

What do you mean by helper classes? You really shouldn't have too many classes that don't represent some concept within your architecture. Yes, there are times when it makes sense to have a class (or method) that just provides some sort of generic functionality to a variety of classes, but generally you want your classes to represent some concept. If you have a lot of classes that you can only categorize as "helper", this is, IMO, a code smell that you may be writing procedural, rather than object-oriented code.

Oh, and to answer your question, as long as they are in the same solution, you should simply be able to add a project reference. Visual Studio will take care to rebuild your projects and update the references as necessary when you make changes.

tvanfosson
I don't use a lot of helper classes, but there are times when reusable code is important (DRY). Like sending an email, logging data in the health monitor, or simply getting user data like OS, IP, Browser Version, etc.
rockinthesixstring
@rock - but then you should have a MailClient, a Logger, and Browser class, not a generic "Helper" with disjoint methods that send mail, log messages, and translate the information in a Request to bits of user data. Perhaps we simply using different semantics, but to me a "helper" class is an adjunct class that doesn't represent a conceptual entity, but contains methods that perform some related tasks for a variety of other (unrelated) classes. For instance, I have an ActiveDirectoryHelper that rolls up some functionality from the .NET AD classes into something more manageable.
tvanfosson
but the point is still the same. I would put the MailClient, the Logger, and the UserData classes in a separate project rather than somewhere within the MVC application.
rockinthesixstring
@rock - absolutely. I always have separate projects for things like Data, Web-related, and common library classes. I was just observing that, depending on your meaning and how you use them, you may want to move to a more OO design. Obviously, I can't tell without code, but the way you described it raised a red flag for me.
tvanfosson