There are a few reasons you’d want to take them out. It’s pointless. They add no value. It’s confusing. What is being used from that namespace? If you don’t, then you’ll gradually accumulate pointless using statements as your code changes over time. Static analysis is slower. Code compilation is slower. On the other hand, there … Read more
The using syntax can(should) be used as a way of defining a scope for anything that implements IDisposable. The using statement ensures that Dispose is called if an exception occurs. //the compiler will create a local variable //which will go out of scope outside this context using (FileStream fs = new FileStream(file, FileMode.Open)) { //do … Read more
The fact that you need to ensure that the object is disposed indicates a design flaw. It’s fine if disposing is the polite or efficient thing to do, but it should not be semantically necessary. There is no way to enforce that an object is disposed of via the using statement. However, what you can … Read more
Since you have a using block, the Dispose method of the SQLCommand will be called and it will close the connection: // System.Data.SqlClient.SqlConnection.Dispose disassemble protected override void Dispose(bool disposing) { if (disposing) { this._userConnectionOptions = null; this._poolGroup = null; this.Close(); } this.DisposeMe(disposing); base.Dispose(disposing); }
Let’s get controversial! I disagree with the general MVC + EF consensus that keeping a context alive throughout the entire request is a good thing for a number of reasons: Low performance increase Do you know how expensive creating a new database context is? Well… “A DataContext is lightweight and is not expensive to create” … Read more
You don’t manually destroy .Net objects. That’s what being a managed environment is all about. In fact, if the object is actually reachable, meaning you have a reference you can use to tell the GC which object you want to destroy, collecting that object will be impossible. The GC will never collect any object that’s … Read more
Unfortunately, the using directive does not do what you want. You can say: using Frob = System.String; and using ListOfInts = System.Collections.Generic.List<System.Int32>; but you cannot say using Blob<T> = System.Collections.Generic.List<T> or using Blob = System.Collections.Generic.List It’s a shortcoming of the language that has never been rectified.
When you call GetAllAnimals it doesn’t actually execute any code until you enumerate the returned IEnumerable in a foreach loop. The dataContext is being disposed as soon as the wrapper method returns, before you enumerate the IEnumerable. The simplest solution would be to make the wrapper method an iterator as well, like this: public static … Read more
No, it is not safe – it won’t pollute another namespace, but it is dangerous for other reasons: A using directive will import anything that is currently visible by the name you specify into the namespace where you use it. While your using will only be visible to users of MyNamespace, other things from “outside” … Read more
I don’t know exactly, but my guess is that allowing this at class scope could cause confusion: namespace Hello { typedef int World; } class Blah { using namespace Hello; public: World DoSomething(); } //Should this be just World or Hello::World ? World Blah::DoSomething() { //Is the using namespace valid in here? } Since there … Read more