I have a small Utility library containing some useful utility methods which have been fully unit-tested. At the moment, my library has no external dependencies. I am toying with the idea of adding logging to my classes which might be useful for debugging purposes. But this would mean bundling logging libraries along with my project.
My question is: should I keep my library dependency free? Are there any advantages of doing so?
I would add a logging interface that the can be used to abstract the logging. Then the allow users to add logging via this interface. You too should use this interface, and you should supply a 'NullLogger' built into your library that would be used if no other logging is needed.
You can make it easy to not use the NullLogger by asking users to configure a new one, simply by config file or by run time discovery.
Use Java Logging. It's part of JRE/JDK so no external libs are needed.
Check out examples.
There are many advantages of doing so, not the least the ability to run on most any operating system.
One way of keeping your library pretty dependency free, is to require it to initialized prior to use. Then you would in your_lib_init(); function take a function pointer to logging backend. This means, the backend can be rewritten for any platform it might run on.
Also figure out, if you want a library totally free of all library dependencies, or one that depends on the standard class path. If it is pure Java, it will run on J2ME, Android, native compiled Java with GCJ and what not. If it uses class path, it will be portable across all class path implementations, in practice wherever OpenJDK runs.
Pro:
Your library will be much smaller (chances are that you're only using a small part of the full functionality of any dependency)
No update hell (like your code needs library C, version 2, product X needs your code and library C, version 1).
You won't need to bend your spoon to the whims of someone else (say the library you goes from 1.x to 2.x -> you need to update your code)
Con:
Wasted code if product X also needs the library
How smart are you? Chances are that you can't match the thought, wisdom and time that already went into the library.
PS: If you want to support logging, add slf4j to your code; this is a 30KiB API which allows users of your code to use any logging framework out there. Do not use commons-logging.
Related
I wanted to know if you suggest (in your opinion) using / building a logger wrapper such as Common.Logging in order to use some kind of logger?
I presume that the use of such wrapper is to :
1. Enable changing the logger library when needed.
2. Make the API easier.
In the end does it really matters ? or the loggers are easy to use and do not need to simplify it or change the logger just like that.
Thanks.
I have written a wrapper logging library that uses health monitoring for asp.net sites and log4net for windows/console apps. This way the logging interface always stays the same and is easy to be used enterprise wide. In our case, we only wanted to log a few categories, error/debug/info etc. If you think you need to use some special features of a specific logging library, you may choose to implement it directly. If you are using any third party logging libraries, it may be good to have a wrapper because what if the support for that is stopped or you need to move to a better one later.
The decisions are always almost dependent on your specific needs and future plans.
I wouldn't do this without a good specific reason to do it.
I think that it's not very likely you are going to want to change the logging library, unless you chose badly in the start.
What you probably would want is to use features specific to the logger you chose, but that means the wrapper is not really useful.
I have an application that I have designed and this app has a pretty decent core dll that contains an API that my main view's exe uses. I would like to allow other developers to access this core dll as well but I don't want them to have as much access as me since it would be a security risk. What is the standard way of exposing my core dll? Are there any particular design patterns I should be looking at?
I'm using C#
Edit: my question was a little vague so here is some clarification
My program is deployed as a windows exe which references the core.dll. I want other people to create extensions which dynamically get loaded into my program at start up by loading dlls in the /extensions directory. The 3rd party dlls will inherit/implement certain classes/interfaces in my core.dll. I only want to give 3rd parties limited access to my core but I want to give my exe additional access to the core.
I should mention that this is the first time I have written a program that imports DLLs. Perhaps this whole method of allowing users to add extensions is wrong.
How do I modify/expose my API for
other developers?
To deliberately allow other developers to work with an API you've built touches on many things, which can be broken into two areas:
Resources (documentation, samples, etc) that makes it easier for them to understand (yes - basically an SDK).
Architecting, constructing and deploying your solution so that it's easy to actually work with.
Examples include:
By packing it in a way that suits re-use.
By using naming conventions and member names that others can easily follow.
Documentation, samples.
Providing the source code (as open source) if you're happy for them to modify it.
I would like to allow other developers
to access this core dll as well but I
don't want them to have as much access
as me since it would be a security
risk.
Ok, so this gets us right into the second area - the actual solution.
The problem you have is not a trivial one - but it's also quite do-able; I'd suggest:
Looking into existing material on plugins (https://stackoverflow.com/questions/tagged/plugins+.net)
Personally, I've found using attributes and Dependency Inversion to be a great approach.
There's also stuff like the Managed Extensibility Framework which you should consider.
The big issue you face is that you're into serious architecture territory - the decisions you make now will have a profound impact on all aspects of the solution over time. So you might not be able to make an informed decision quickly. Still - you have to start somewhere :)
The "design patterns" in terms of an API are more related to things like REST.
I don't want them to have as much
access as me since it would be a
security risk
Then i would (for the sake of maintenance), layer on top of the core DLL extra logic to prevent this.
The thing is, the "clients" call the API, not the Core DLL.
"How" the API accesses the Core DLL is under your full control. Just only expose operation contracts that you wish.
Since you're using C#, I would look at Microsoft's Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries and use FxCop to in-force many of them (latest version here). This won't be all you'll likely need, but it would help put you in the right direction.
Also, take a look at the freely available distillation of Framework Design Guidelines by the same author.
I've inherited an enormous .NET solution of about 200 projects. There are now some developers who wish to start adding their own components into our application, which will require that we begin exposing functionality via an API.
The major problem with that, of course, is that the solution we've got on our hands contains such a spider web of dependencies that we have to be careful to avoid sabotaging the API every time there's a minor change somewhere in the app. We'd also like to be able to incrementally expose new functionality without destroying any previous third party apps.
I have a way to solve this problem, but i'm not sure it's the ideal way - i was looking for other ideas.
My plan would be to essentially have three dlls.
APIServer_1_0.dll - this would be the dll with all of the dependencies.
APIClient_1_0.dll - this would be the dll our developers would actual refer to. No references to any of the mess in our solution.
APISupport_1_0.dll - this would contain the interfaces which would allow the client piece to dynamically load the "server" component and perform whatever functions are required. Both of the above dlls would depend upon this. It would be the only dll that the "client" piece refers to.
I initially arrived at this design, because the way in which we do inter process communication between windows services is sort of similar (except that the client talks to the server via named pipes, rather than dynamically loading dlls).
While i'm fairly certain i can make this work, i'm curious to know if there are better ways to accomplish the same task.
You may wish to take a look at Microsoft Managed Add-in Framework [MAF] and Managed Extensibiility Framework [MEF] (links courtesy of Kent Boogaart). As Kent states, the former is concerned with isolation of components, and the latter is primarily concerned with extensibility.
In the end, even if you do not leverage either, some of the concepts regarding API versioning are very useful - ie versioning interfaces, and then providing inter-version support through adapters.
Perhaps a little overkill, but definitely worth a look!
Hope this helps! :)
Why not just use the Assembly versioning built into .NET?
When you add a reference to an assembly, just be sure to check the 'Require specific version' checkbox on the reference. That way you know exactly which version of the Assembly you are using at any given time.
I'll write a application but I've never experienced to allow people to use my application programming interface before.I mean how kinda design I should make to let people use my methods from outside world like API.
Please some one show me a way.I am kinda new to this.
Expose as little as you can. Every bit you publish, will return to you x100 in next version. Keeping compatibility is very hard.
Create abstractions for everything you publish. You will definitely change your internals, but your existing users should stay compatible.
Mark everything as internal. Even the main method of your application. Every single method that could be used, will be used.
Test your public API the same way you would for interfaces. Integration tests and so on. Note that your API will be used in unpredictable ways.
Maximize convention over configuration. This is required. Even if your API is a single method you will still need to support this. Just makes your life easier.
Sign, and strong name your assemblies, this is good practice.
Resolve as many FxCop and StyleCop errors as possible.
Check your API is compatible with the Naming Guidelines of your platform.
Provide as many examples as you can, and remember that most of the usage of your API will be Ctrl+C and Ctrl+V from these examples.
Try to provide documentation. Check that you do not have GhostDoc-style auto-generated documentation. Everybody hates this.
Include information on how to find you.
Do not bother with obfuscation. This will help you and your users.
ADDED
API should have as less dependencies as you can. For example, dependecies on the IoC containers should be prohibited. If your code uses it internally. Just ilmerge them into your assemblies.
It may not be the funniest reading, and certainly not the only reading to do on the subject, but while designing your class library (your API), do check in with the Design Guidelines for Developing Class Libraries every now and then, it's a good idea to have a design that corresponds a bit with the .NET Framework iteself.
Make your methods you want to expose to the outside world public.
I found this presentation to be particularly insightful:
How to Design a Good API and Why it Matters
http://lcsd05.cs.tamu.edu/slides/keynote.pdf
One way to do it is to create a DLL for your main functionality that others will use and an EXE that calls the methods in the DLL. If you want your application to support plug-ins, have a look at the System.AddIn namespace.
If you want to see what's new in this area, check out the Managed Extensibility Framework. It's a new/"unified (see the comments...)" method for exposing features for add-ins and other extensibility/modularity.
I stand in front of a little problem; I want to create a modular software.
Let's make it more general and not specific for my case. What I want to create is a software which loads dlls and those dlls adds features to the software.
Think of the dlls as xvid, divx or whatever additional codec, feature to your favorite video-player. I want a more custom modular program though, in my case I'm creating a software to handle Customers, Invoices and Products and different users might have different needs and therefore I need to handle this somehow!
However, re-compiling the software and specificly sending the new files to each different user is "stupid" I would rather create a modular software ( don't actually know if this is the correct term ).
So what I was thinking is that I begin creating a pattern of which my DLL's should follow.
Then I create a Module handler in my software which loads the actuall DLL and calls the method in it ( here's where the pattern come in! ).
What I'd like to know is; Am I on the right track?
Might you guys give me some pointers or examples on this matter?
This is all in C#, but would of course be interesting to see how it would differ in Java, Python or C++ too.
create a common interface IMyInterface for your classes which should include everything that is common between all of your Moduals. You should look into the Managed Extensibility Framework I believe you can get it from Codeplex.
You have to have a purpose. You either need the module to conform to some kind of interface or something the app can handle (like a method with a known attribute that you find via reflection). The interface then performs known functionality like invoice creation, invoice printing, etc.
Alternatively your app has to conform to some interface and uses hooks for the module to use to inject itself into your app.
Plugins would be good for something that can be easily sliced up (media codecs). Hooks would be good for something with a well-defined event model (like a web server). Which you use depends on how you want your modularity for customers, invoices, etc. to work.
Here is a similar SO thread. Here's a list of dependency injection frameworks, Microsoft's is Unity. Also, you can look at the Enterprise Library codebase to see how they implement their provider architecture, such as in the caching application block where you can plug in your own caching provider.