![]() They could all potentially become dependencies of Controllers or even eachother. You may already be using ready-built components such as thoseįound within the Enterprise Library. All of these could be implemented as components. An emailing service, a logging service, caching, validation etc. When you view Data Access as a "component" of your application, you should also start to see that there are other areas in an application which could be viewed as components. But it happened nevertheless and was forced on us. And I can to an extent sympathise with that: the only data access changes I have ever made to an application were through my own choice. "Oh, but that will never happen to me", you say. Now imagine that these Controllers had 20 or 30 Actions, and that there are 20 or 30 Controllers. OK, you think - it's just a couple of lines that were changed. In other words, you began by using LINQ to SQL, and then were required to change the data access to the Entity Framework (or ADO.NET, nHibernate, Typed DataSets or any number of other methods). So what's the problem with that? Well, imagine that the two versions are an example of "before" and "after". There is no separation of concerns here in that the data access layer is embedded in the Controller. In the second, an Entity Framework ObjectContext is referenced, and a is passed to the View. In the first version, a LINQ to SQL DataContext is instantiated and referenced, and a object is passed to the View. However, in both versions, the specifics of the dependency is hardcoded into the Controller. Both versions have a dependency on the data access service or layer, in that neither controller can do their thing without it. One uses LINQ to SQL (the first one) and the second uses the Entity Framework for data access. ![]() Just to clear up any initial confusion, yes - the example above is more or less the same code twice. Private ContactManagerEntities entities = new ContactManagerEntities() Public class ContactController : Controller Private ContactManagerModelDataContext entities = new ContactManagerModelDataContext() So far, you may be none the wiser, so I will use a bit of code based on the Contact Manager ASP.NET MVC tutorial to help illustrate theīasic problem that they or it are/is intended to solve: public class ContactController : Controller DI is one way in which IoC can be applied,Īccording to one school of thought. There are quite a few definitions of IoC, but the basis behind it is always the same - it helps towards a loosely coupled architecture. IoC is a principle, or an architectural pattern. It's just that MVC supports these notions particularly well. I should start by stating the IoC and DI are not unique to ASP.NET MVC. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |