Are there any good libraries or wrappers for Authorize.net? The code samples available from their site seem a little ... raw. I'm looking for an easy to use, object oriented API that I can simply set some properties, and it takes care of all the plumbing code under the hood.
I've found a few random blog posts of people offering their code that they've written, but code offered in a blog post doesn't give a high degree of confidence generally that it's been well tested. I mean, we'll consider these if we have to, but we'd prefer something that looks like it's gone through some sort of release/testing cycle ... even if it's just that it has been posted on codeplex or something.
Thanks! :-)
A little late answering, but perhaps this?
http://code.google.com/p/payment-processor/
I use SharpAuthorize.com on a few eCommerce sites. One of which makes around $10K / month...
MinimumCreditCard authNet = new MinimumCreditCard()
.Login("testdrive")
.Password("password")
.TransType(TransType.AUTH_CAPTURE)
.CardNum(_cardNumField.Text)
.ExpDate(_cardExpField.Text)
.CardCode(_cardCodeField.Text)
.Amount(8.00);
if (authNet.Authorize())
{
// Money in your pocket!
}
It is noted on the site, but you should use a transaction id instead of the username and password in real code.
See my answer here, it should help you out. In my answer, I point to a blog post as a reference. You may need to view the revisions to see my whole answer, though. For some reason it is getting cut off for me. Check out the Gateway Provider Implementations section of the blog post. It should help you out and get you going on implementing your own code for talking to the Authorize.Net API. I've used a similar implementation and it has worked well for me.
Related
I wrote an app in which there is a ton of comments.
This may be a bit unusual, but I would like to know if there is a way in Visual Studio to elegantly arrange the comments in a dedicated file. Or, is there a way to write text somewhere in a text file?
It is true that using comments is great, but my code is still congested.
Currently I plan to use a new class for comments, which will only contain comments with details on the parts of the code that are concerned.
If you have a better idea, thank you very much for sharing it.
I can't stress enough how much of a bad idea this is.
Code comments are best:
Being near the code they concern
Short and simple
Used sparingly - code often changes, comments can very quickly fall out of sync with this, and then before you know it the comments are doing more harm than good.
If there really is some functional explanation you're trying to get across, e.g. why something is needed and how it works, rather than how to use it, I'd recommend writing a document to explain this.
There are all sorts of ways to do this:
Word documents on a shared system (e.g. a network drive / sharepoint)
A wiki system online / internally (e.g. Atlassian Confluence, or GitHub wiki)
(to name a couple)
As per other user's suggestions though, you should ensure that there aren't a lot of comments as they just add noise (something you're clearly discovering).
Sidenote: I once worked for a company that insisted on using comments everywhere, every function had to have a banner comment with its name, signature, who wrote it and an edit history (even though we used source control), and nearly every line of code had to be commented to state what it was (supposedly) doing. If you're in a similar position, perhaps try to explain the problems this causes?
Can someone help me with a link to an article, or a link to a SO post that contains a link, on why its not a good idea to model business rule violations with exceptions. I'd also be happy with a reference to a book and page, if the book was available on Safari, and an extract from the book would be double plus good!
I've seen plenty of good reasons in questions and answers I've looked at on SO, but others need something a little more authoritative (something in the Fowler/Evans league would be nice).
Thanks
Though I have not read these completely, I think these links (one of them is from Google Books) should be useful to you as they are mostly related to modelling business rules authored by Ronald G. Ross (brcommunity.com):
http://books.google.co.in/books?id=Uyv9hMOt6BsC&pg=PA72&lpg=PA72&dq=business+rule+violations&source=bl&ots=8fb5Vqgi3K&sig=DNUkrv4wNZTX755rVk2gv0upzUs&hl=en&sa=X&ei=QYsFT7ezEOf10gH68tmLAg&ved=0CFsQ6AEwCDgK#v=onepage&q=business%20rule%20violations&f=false
http://www.brcommunity.com/b335.php
I don't think you'll find an authoritive answer in any book. Some people will claim throwing exceptions is very expensive in C#. Others (like me) will tell you to not worry about it, unless you're building a semi-realtime system. I've been throwing RuleViolationExceptions in all my major enterprise-class systems because I've seen that this works a lot better than having every method in you domain return some kind of error code. In fact, I think it's a best practice, so I've included this in my Silverlight Cookbook project.
Today I found out about an interface I'd never heard of before: IGrouping
IEnumerable<IGrouping<YourCategory, YourDataItem>>
I am fortunate to have access to some of the best programming books available, but seldom do I come across these kinds of gems in those books. Blogs and podcasts work, but that approach is somewhat scattershot. Is there a better way to learn these things, or do I need to sift through the entire MSDN library to discover them?
Eric Lippert's blog. The real guts of C# - why there are some limitations which might seem arbitrary at first sight, how design decisions are made, etc.
Alternatively, for more variety, look at the Visual C# Developer Center - there's a whole range of blogs and articles there.
Oh, and read the C# spec. No, I mean it - some bits can be hard to wade through (I'm looking at you, generic type inference!) but there's some very interesting stuff in there.
The best place to start is Jon Skeet's C# Coding blog: http://msmvps.com/blogs/jon_skeet/
He regularly covers stuff you won't see anywhere else.
How about the Hidden Features series of questions?
Hidden Features of C#
Hidden Features of ASP.NET
And many more...
I personally like the way of discovering hidden features on my own while solving a specific problem. In the end, a hidden feature that you never needed to get something done is of questionable value. It just adds clutter to the brain.
The way to do it is to use the MSDN library to look things up. Then take a little time to look around what you found.
That's especially important with the pure API documentation. For instance, I just browsed to http://msdn.microsoft.com/en-us/library/system.xml.xmlreader.aspx (note how that URL is formed). When I look in the Contents pane on the left, I see everything from XmlDocument (and XmlDocumentFragment) all the way down to XmlReader. In the middle are some things I rarely or never use, like XmlNamespaceScope and XmlNodeOrder.
From time to time, spend a little time on "abstract knowledge". Sometimes, it's good to look up from the trees to learn your way around the forest. You never know when you'll need something you've learned to get you out of the woods.
For the people who don't know IGrouping:
http://msdn.microsoft.com/en-us/library/bb344977.aspx
I often read useful stuff on the Viual Studio Startup page and start clicking around to other keywords/areas. Not too promote StackOverflow too much, but you'll find some hidden gems here as well, simply by looking at how other people write code.
For example:
Hidden Features of C#?
A month ago I searched for some tools that will generate C# classes out for my SQL database/tables. So I don't have to write DAL classes manually and to save a lot of time.
I came across "ORM" and subsonic. I watched the webcasts on the homepage http://subsonicproject.com/ and was pretty impressed by it.
But I am still missing more documentation/knowledge to feel comfortable with subsonic to use it in our projects. Today I read about the "migration" feature somewhere - accidental.
How to get into subsonic? How to get more comfortable with it? How to know about all the features/possibilities it provides? Are there any good blogs/tutorials/whatever for subsonic?
Unfortunately, the best SubSonic "documentation" is in the form of screencasts, but they are very easy to follow.
Quite a lot about SubSonic on Rob Conery's (original creator) blog http://blog.wekeroad.com/tags/subsonic/.
Personally found the best thing is (like Matt said) to just use it, set it up in external tools in VS, get the connection string and a few other config settings sorted, and you're just about good to go. You can get the basics down in an afternoon.
The forum is quite active http://forums.subsonicproject.com/forums/, and a good place if you get stuck.
SubSonic is irritatingly short on documentation (which is one reason I abandoned it). Scott Kuhl wrote a "Getting Started with SubSonic" document (just Google his name and SubSonic) but parts of it appeared to be out of date.
Here is Scott's blog - a place to start at least.
Here is the document's home page. I was curious as to whether the document is indeed out of date and I think it is: the web page has a last updated date in 2006.
Unfortunately, I know of no other documentation and I did look for it.
Update: See the link to documentation that Rob Conery provided in his answer.
I admit it - our docs suck :(. I did try to put a site together:
http://subsonicproject.com
Hope this helps.
Just start using it.
It is very simple and pretty straight forward. There are several screencasts on how to generate your classes with sub commander, once you have that just hit . and see what you can do with them.
I put together a template project referencing SubSonic generated off the Northwind Database. A very simple project, but should easily be enough to get started on your first project. Check it out here:
http://ajondeck.net/post/2008/12/29/ASPNET-20-SubSonic-Project-Template-With-SQL-Server-2005-Northwind-DB.aspx
Over the years as I have gone through school and been working in the industry I have often asked people for advice on commenting. Sadly, as we all know, commenting with many developers is something that is taken as a side note and not much else. With that said I usually get a fairly general answer. Really this does not help much to see what will really help as time goes on.
So, what do you think is the best way to structure C#, with Visual Studio, commenting?
At the very least, I would comment all parts of your public API, using a triple-slash XML comment block. This will make it easy to auto-generate documentation if and when the time comes.
Beyond that, I would comment any particular algorithms or pieces of code which are going to be hard to decipher in six months time. This 'selfish' approach to commenting (i.e. assume you'll have to maintain this code later) often leads to the best balance of ample documentation without overkill.
I try to follow some basic guidelines when writing comments.
Comments should be simple
Comments should provide clarity
Write documentation before you write implementation
Document why you're doing something, not what you're doing.
Use built-in (XML-style) comments for interfaces, methods, properties, and classes.
Provide a summary at the top of every file (e.g., Something.cs) with the file name, description, development history, and copyright information
Add comments for bug fixes (with bug number, if appropriate)
Make use of helpful annotations like //TODO //BUG and //BUGFIX
Don't comment out code unless you plan to use it
Add comments above the line(s) of code they apply to, not to the end of the line
Try to limit comments to a single line
Use // instead of /* */ for multi-line comments
Be clear--do not use "foo," "bar," etc.
Follow casing rules where appropriate (i.e., camelCasing and PascalCasing)
"Plenty and often"
--Bilbo, The Hobbit.
More seriously, comment things that are not obvious, and tell the reader what the goal of the code is, and perhaps why you chose it.
That's not going to change based on language.
Personally I use a combination of triple slash, SandCastle XML comments and inline comments for more complicated sections. Comment often but keep it concise, nobody needs to read reams of fluff before then can figure out what something does :-)