Tag Info

Hot answers tagged

20

Don't IOC containers break a lot of these principles? In theory? No. IoC containers are just a tool. You can have objects that have a single responsibility, well separated interfaces, can't have their behavior modified once written, etc. In practice? Absolutely. I mean, I've heard not a few programmers say that they use IoC containers specifically to ...


14

I'll go through your points numerically, but first, there's something you should be very careful of: don't conflate how a consumer uses a library with how the library is implemented. Good examples of this are Entity Framework (which you yourself cite as a good library) and ASP.NET's MVC. Both of these do an awful lot under the hood with, for example, ...


11

Does using an IoC container necessarily violate OOP/SOLID principles? No. Can you use IoC containers in such a way that they violate OOP/SOLID principles? Yes. IoC containers are just frameworks for managing dependencies in your application. You stated Lazy injections, property setters, and a few other features I haven't yet felt the need to use, which I ...


9

The file downloader has two external dependencies: a connection to Git is where data comes in. A connection to the file system is where data goes out. To be a unit test, your test should abstract from both these collaborators - you don't want to test the Git network protocol, and you don't want to test file system code either. That leaves the behaviour of ...


9

If you can't think of a good reason TO use dynamic, then you are foregoing potential compile time checks for little to nothing in return. I prefer generics over object, and prefer object over dynamic, unless I need to interact with a dynamic language ScriptEngine or a dynamic container like a web form where its reasonable to handle the potential runtime ...


5

dynamic was primarily introduced as a way to allow C# to interop with languages such as Python, which is not statically typed. If you are using it out of this context you are probably forgoing functionality. As you said, in the limited context that you present, you are much better off using generics (the KeyValuePair class looks pretty much like what you ...


4

There are a number of reasons why you might want to use an IoC container. Unreferenced dlls You can use an IoC container to resolve a concrete class from an unreferenced dll. This means that you can take dependencies entirely on the abstraction - i.e. the interface. Avoid the use of new An IoC container means that you can completely remove the use of ...


4

Your test is not useless. A unit test FileDownloaderFixture tests the FileDownloader not more, not less. Don't expect a unit test to test more than one unit. To test GitHubProvider.Download, you need a second, different test. Since there is an external resource involved which is almost completly out of control of your test environment, it probably does not ...


3

passing private methods as arguments to other objects comes across as fundamentally strange to me. They're called first-class functions. It's a perfectly valid technique. That said, are you sure that this isn't all a bit over-engineered? What's wrong with simply doing something like this? user.SetPassword(newPassword); If you're bothered by ...


3

I see multiple mistakes and misunderstandings in your question. The first major one is that you are missing distinction between property/field injection, constructor injection and service locator. There has been lots of discussion (eg. flamewars) about which is the right way to do things. In your question, you seem to assume only property injection and ...


3

Don't IOC containers both break, and allow coders to break, a lot of OOP/SOLID principles? The static keyword in C# allows developers to break a lot of OOP/SOLID principles but it's still a valid tool in the right circumstances. IoC containers allow for well structured code and reduce the cognitive burden on developers. An IoC container can be used to ...


3

The answer is that if dynamic types make your code better, produce a better outcome and make your life easier then of course you should use them. That's what they're for! You should absolutely not concern yourself with boxing/unboxing, which is pretty efficient apart from imposing some load on the garbage collector. Look at the generated code for dynamic ...


3

In a properly decoupled architecture, your application should have no knowledge of the physical database model. To put the table and column names in your classes creates a dependency that could break your application if there are major changes to the database beyond simple table and column changes. For an application of some size and complexity, the better ...


2

I'm thinking of putting the names of the tables and columns and such into a single static class... Don't do this. If you want to eliminate magic strings, please do yourself a favor and create one static class per table underneath a shared namespace. A single static class to manage all table and column names would quickly turn into a big ball of mud.


1

sAMAccountName (or uid in most Unixy LDAPs IIRC) is not unique - its only unique within each domain. If you want unique, you use the ObjectGUID - if a user gets renamed or moved, this is the only bit that will remain constant. That means you need this if you have totrack a user getting a new username or moved to a different ou.


1

You have to have a bit of context here: I think the main point missing is that this was a pre C#2.0 feature, which means it's a feature that came before nullable types. The page that describes the overloading of the 'true' operator is clearly geared towards the direction of having a nullable boolean without using a nullable type as support. But there are ...



Only top voted, non community-wiki answers of a minimum length are eligible