2

I have an ASP.NET project that contains many classes.

I am thinking about creating a class library for the class files so that the code can be reused in other applications. There are two options:

1) Create a class library containing all the classes 2) Create a class library for only the classes that contain code that will be shared and then perhaps use interfaces

Is there any true benefits of option 2? Option 1 would be beneficial because all the code would be in one place.

w0051977
  • 15,099
  • 32
  • 152
  • 329
  • 4
    If you really want to share these classes, there is an issue of *coherency.* The library should not contain classes that are specific to your ASP.NET project, in other words; it should only contain classes that have wide applicability to other projects. You can have another class library that contains classes specific to your project. – Robert Harvey Jul 03 '12 at 19:50

2 Answers2

3

I would recommend option #2.

If the code will be reused by other applications, I wouldn't add the additional classes in there, as it would clutter up the library. I would put the remaining classes in the App_Code folder of your ASP.NET application that are specific to that application.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
rag9
  • 484
  • 1
  • 5
  • 17
  • Thanks. All the classes are currently in the AppCode folder of the ASP.NET app. Could you explain what you mean by "clutter up the library". I was thinking about exposing the shared functionality in a web service. I am not sure whether the web service approach would be best. All the apps that access the shared code are currently on the same server. – w0051977 Jul 03 '12 at 19:58
  • Sure @w0051977. Let's say you have ClassA and ClassB, and Application1 and Application2. Assuming that ClassA is something you want to share in a class library between both applications, but ClassB is specific to only Application1. What I meant by "clutter up the library" was that when accessing it from Application2, with both classes in the library, you would see YourLibrary.ClassA and YourLibrary.ClassB - when really all that Application2 cares about is ClassA. It may sound a little picky, but I think it would be cleanest to only put the classes you want shared in the class library. – rag9 Jul 03 '12 at 20:13
  • surely the "clutter" would just be in another folder (inetpub instead of system32) if I chose option 1? – w0051977 Jul 03 '12 at 20:52
  • I see where you're coming from, but I wouldn't call that clutter since that's the way it's intended to work. By putting the application specific classes in the App_Code folder, they'll automatically be compiled into a DLL and deployed in the Bin folder of your web application. Another option would be to put the application specific classes into another class library. I know some developers like to do this rather than using the App_Code folder, but I don't see much of an advantage in doing it. More about the App_Code folder here: [MSDN](http://msdn.microsoft.com/en-us/library/ex526337.aspx) – rag9 Jul 03 '12 at 21:17
1

If your purpose is re-use, then it makes sense to bundle together classes that will be reused. However, this is not the only concern when developing a class library. Ultimately you want high cohesion and low coupling, not only at the class/method level, but at the class library (component level) as well. See:

http://jasoncoffin.com/2011/03/10/cohesion-and-coupling-principles-of-orthogonal-object-orientated-programming/

Loose Coupling and OO Practices for Beginners

Community
  • 1
  • 1
ssis_ssiSucks
  • 1,476
  • 1
  • 12
  • 11