DI stands for Dependency Injection. It is a subset of of a larger pattern of architecture pattern of IOC - Inversion of Control. Example -- In a large project you have been asked to put error handling in business class methods and you should log the errors. Some methods have been exposed to you by the framework e.g. Logger.Save(exception e). All you are doing in the catch block is calling this Save method.Now in the background you really don't know, where this log is being written actually! Is it a flat file, in a db table or some other data source. All Even if it is DB table, there can be a variance whether the db is MS Access, MongoDB, SQL Server or Oracle. There is a dependency for each of this technology as the syntax is different. So when a framework abstracts this from you and encapsulates the actual implementation of where and how the log is written, this is what is called as dependency injection. All you know is the signature of the method SAVE(). The implementation of this save is handled differently and based on final production deployment -- where some customer can choose oracle vs sql server, the product group configures the actual implementation to this save. They injected the dependency, without you calling the actual one.Loosely coupled code is when your code do not have too much of association and dependencies. Example, if you have written a method1 that calls another object or service, then during design time itself, you need to know what that service endpoint or object type is. Instead, if you would have programmed in a way where you have published the event, and the service you intended to call earlier, simply subscribe to this event, then there is no hard coupling. The caller don't know who is processing the request further, neither the subscriber knows, who published the information that it is supposed to process. Other than events there are multiple other ways to make the code loosely coupled.

Easly understandable and maintain