there should be base interfaces for mocking on classes with business logic

classes with business logic like CloudBlobContainer, CloudStorageAccount, CloudBlobClient, CloudFileClient, CloudQueueClient, and CloudTableClient should have a base interface that allows to replace those classes easily with mocks in unit tests.

[PureKrome]

Do you really ever want to reference a 3rd party library from your business code.

Yes! TOTALLY!

Bad Idea.

Sigh…

I know exactly what the problem requires to solve it … It requires me to throw a message on an AZURE Queue. Could I have gone to AWS? Sure. MB? sure! hell, i could have used channels or even a text file. So many ways to solve a problem …

Bad Idea. You have to recompile your code when you: Want to write to an Azure topic or a Service Bus Queue / Wan to write into an AWS Queue.

Okay … so now you’re going to suggest that I also abstract my database because … you know … we all switch from MS-SQL -> Postgres -> MySql -> NoSql DB’s -> text files -> back to MS-SQL.

You can abstract anything to the N’th degree. Go nuts. But at some point, you’ll need to actually end up calling something. A good architect has to make a decision about what infrastructure they will end up using and hopefully stick to it. If you’re going to play the “we might keep moving to different infrastructure” cards, then you have different problem(s). For years and decades heaps of people have cried out loud about abstracting everything away to buggery. Yay! lets abstract ORM’s cause an ORM isn’t already an abstraction. Seriously. The number of times people swap infrastructure is pretty damn low. How many times have you spent months working against Sql-Server … to now get told you’re moving to Postgres … and then 5 months later again to MySql? Same applies across the board. And if you can’t make a decision, then enjoy the flip flopping.

Same goes for your ‘Storage’ infra.

Solution: Write your own IQueueRepository interface in Business, Implement it in a Repository as QueueRepository

HA! I called it, above!

Why are the methods virtual? So you can use dependency injection to create exception handling / retrying / logging just by interception.

Okay - again, I’m not going to get into opinions of what is good vs bad. It’s all tabs-vs-spaces. An echo chamber of “i’m right, you’re wrong”. If you don’t like DI/IoC - fine. If you like abstracting everything away because there might be a chance in some future that you might switch providers/infra … then fine. Good luck.

My example was clean and simple and (most importantly) about how to unit test against the given SDK. If you have some ideological war against virtual methods vs interfaces then go for it. But please don’t make false assertions that we cannot mock against the given SDK, given I just showed you a really simple example of it.

Useless Info: I’m personally a fan of interfaces and use em all over the place. I just am more old school and prefer interfaces to virtual methods. I’m not right or wrong. But I do know how to use virtual methods in unit tests and for that, I’m not going to hate at all.

Hope this gives you some background why the rule: “There is no interface” make sense here.

[seanmcc-msft]

I’m not sure why we chose to use virtual methods instead of interfaces, the One Azure SDK review board made this decision for all new .NET Azure SDKs.