Can someone please provide me a simple example of DI and IoC?
I understand the first one but was unable to get an implementation of the second one.
I'm working with MVC 3 and I really want to use the IDependencyResolver, but I can't understand how.
Is ninject an option or is it required?
Is there a tutorial like nerdDinner and I wasn't able to find it?
Can somebody give me a link to study it?
In order to grok real world DI and its patterns and anti-patterns quickly, I recommend getting DI in .NET. (I've ordered it already EDIT: And it was a page turner that taught me a lot and should teach people of all experience levels well)
Failing that, read all Mark Seemann's high-rated posts here.
I personally learned from the ninject wiki, but that, while excellent, is Ninject 1.0 specific.
don't use IDependencyResolver. It has nothing to do with Inversion of Control, and it's fundamentally broken. If you want to learn how to use IoC Container properly with MVC 3 see this tutorial (uses Windsor).
This isn't my example, but is one I just ran across while looking for a simple, functional example. It uses NInject and the final IoC functionality of .Net MVC 3.
http://www.shahnawazk.com/2010/12/dependency-injection-in-aspnet-mvc-3.html
Simple downloadable example project at the bottom of the article.
I cant answer for asp related techs, but on the academic side, the fact that you are using DI implies that you have inverted control.
Ill make it explicit -- when you do not invert control, you basically make the various components of an application resolve their own dependencies. When you invert control, you allow the resolving of the dependencies happen at some other layer. That is the 'inversion' of the control.
Related
I want to make one mvc3 application which is student management.
I've seen some open source projects.
They have used solution structure like core,data serve rice.
is there any reason to use structure like this?
Usually it is a good a good idea to keep things separated.
By that I mean not mixing up business logic with database management code and having non-UI code in the view files.
This makes it a lot easier for others to understand the code you have written. I also helps you, when you get back to some project after some time to make improvements or correct errors.
I hope this answered your question, if not shot again.
Edit: I found this link explaining how it is done in the MVC framework.
Use layered architecture where you isolate each layer by using the Separated Interface pattern. For the database, use Repository pattern (easiest way to archive that is to use a ORM like nhibernate).
Use an inversion of control container to reduce coupling (with the help of interfaces) and make it easier to handle dependencies between classes.
As stated in the previous answers, you should separate your logical tiers into a minimum of BusinessLogic (Entities,validation,etc..), Data(your favorite ORM), and presentation (MVC).
However, if you are just starting out it may be a little daunting to incorporate all of the more advanced concepts of a SOLID architecture.
Separating logical tiers doesn't always have to mean separate projects. The standard MVC3 template demonstrates this with the "Models" folder. Any entity added to this will be under the namespace Myproject.Models. Later you could re-factor the code in the Models folder into a separate dll,add a reference, and as long as the namespace was still Myproject.Models the MVC app will continue to work.
The same thing could be done for your Data Access layer!
If you're just starting out I would recommend developing your app in the MVC project and separating your DAL and Business Layers with a Folder (Namespace). Once your application is working you can re-factor as needed.
VS2010 Pro + SqlServer Express.
Having been dropped into ASP.NET MVC 3 with no guidance but the web (2 books on order), I can't even get off the ground.
The MVC itself I get. Not a problem.
PHP, Ruby, and even ghastly WebForms firmly tucked into my toolbelt, with a long history of C++ QT client-server development before that.
Tying ASP.NET MVC 3 to a database using EF4 ORM is killing me.
The goals:
Use database modeled by DBA. I can specify all naming conventions, but code first is not an option!
Import to EDMX. This will be regularly updated using VS tools from the DBA's DB, never edited directly.
Generate partial classes from EDMX, for use as model. This will regularly be updated using VS tools, never edited directly.
Use 'buddy' to extend above model class with code as the Controllers/Views need.
Intuitively use the resulting model, pass it to the view, retrieve posts into it for insert/save, etc...
I've seen and read so many blogs, forum posts, walkthroughs, and stack overflow posts regarding this very use case.
I even tried riding the magic unicorn, followed by the latest 4.2beta1 with DbContext generators.
But can't get off the ground.
I follow instructions, but just not understanding how to do anything with it.
What conventions does the 'buddy' require (if any)? How do I use it? How do I get data with it? How do I write data?
Every example looks different. MVC guides are always focused on the UI side. EF guides don't cover usage in the MVC.
These are basic questions, and I'm feeling like the most incompetent idiot in the WWW right now.
Is anyone out there currently using MVC3 & EF4.x in the way I describe above?
This video is a good starting resource. Its a video of a guy creating an app from scratch that uses entity and a sql database (though he makes the db in the video, its still good for seeing some basics in action). You can see how he pulls data from the database, displays it on the page, and saves changes back to the database.
The first question I would ask is why are you stuck on using EF as an ORM or even insisting an ORM at all? I'd choose tools to suit the job here, especially given the constraints of the data layer.
Buddy classes were a concept invented in a day when the main .NET ORMs had no code-first option as ORM-encumbered class instances really don't behave well under things like model binding. Nevermind you could not decorate them with the DataAnnotations one used to indicate fields were required. Typically, the technical requirement is to use [MetadataType] attributes to tie your buddies to your models and perhaps something like AutoMapper to map data to and fro.
All that said, as a guy who has a few apps with lots of buddies and lots of automapping going on, you might want to think otherwise -- it is a bit of a maintenance nightmare. I'm living it.
There are some really good getting-started videos and tutorials right on ASP.NET MVC's site. The "Model (Data)" section is Entity Framework focused and touches on hot/trending topics like Repositories and Units Of Work.
I'm experimenting with ASP.NET MVC3 Razor and I'm fairly impressed. This is the way we'll go.
We use Spring.NET for dependency injection in our framework and I wonder, if it is possible to use it for MVC3 projects as well?
The documentation of Spring.NET is only talking about MVC2, but I guess there will be MVC3 support in future release. Nonetheless I was trying to get it work though. With no success so far.
So my question is, if someone else found a way or workaround or trick to do dependency injection in MVC3 using Spring.NET and if so, how?
I know this is a very general question, but even a honest "sorry this is definitely not possible" or "it should work without any modifications" would help me a lot.
Thanks in advance,
Jan
Yes, even though the the latest Spring.NET release (1.3.1) has explicit support for MVC2, it can also be (pretty easily) used to support MVC3. The IDependencyResolver interface introduced with MVC3 makes IoC integration significantly more straightforward than it had been in the past (offering just one single interception/pluggability point for type resolution where previously there had been multiple places you needed to intercept type resolution calls).
See blog posts like this one: http://blog.alexkyprianou.com/2011/03/07/using-spring-net-with-mvc-3/ for more information and suggestions on how you might go about doing this (its really quite simple compared to the effort/complexity of doing so with MVC1 and MVC2.
It should work without modifications.
After some more investigation and help of colleages I found out, that Spring.NET works with MVC3 - at least as far as I can see it now. My orignal problem was a misformatted xml-file for my injection objects (I didn't post the code in the question).
Still there seem to be issues with object scopes. The scope request doesn't seem to work, since all my objects are still singletons and once created, can not handle more than one request.
I tried to add the well-known attribute singleton="false" and it worked somehow, so my objects will now be created on every request. Good!
However I found out, that Spring.NET's example Spring.MvcQuickStart.2010 also uses the singleton attribute with value false, so probably this is the correct way (and true by default).
I don't know yet, how to handle the session scope, but at least my web application works for requests (singleton="false") and application-wide (no singleton attribute) with Spring.NET and MVC3.
Best,
Jan
I’m about to write quite a big web site that will basically be a forum, divided to (many) different subjects and allow users’ score.
I’ll be using MVC, so I (“naively”) asked this question about how to partition the Model portion of MVC, which is likely to be very large.
Two things I realized from the answers I got:
I really don’t know much about designing software.
There are many ways to implement MVC
So I have now two questions:
(That’s a bit theoretical-) Would
you say designing a software is
completely deterministic i.e.- For a
specific set of requirements there
is one best design? If not- why?
What are the common components
(necessary and optional) of MVC that
I should consider in writing my site
(resources for beginners would be
great)?
Although Java/JSP/Servlet targeted, you may get some useful insights out of this answer. It describes the common patterns to be used in MVC and the approach how to fit them all together. Here's a summary:
Front Controller pattern (Mediator pattern) - the controller
Strategy pattern - the business actions
Abstract factory pattern - to let controller obtain the desired business action.
Facade pattern - to abstract the raw HTTP details away.
State pattern - to introduce a lifecycle which abstracts gathering of request parameters, validation, conversion, updating model values, etc away.
Composite pattern - to create an advanced component tree for the view.
For ASP.Net MVC, a good entry level, free tutorial is the 'MVC 2 Music Store' by Jon Galloway. You can find it here. Note that the current version of ASP.Net MVC is MVC 2.
A more thorough tutorial is the Nerd Dinner tutorial. However the creators are still in the process of updating it to MVC 2. You can check for updates and downloads here.
I would recommend using resources for MVC 2 as there are some significant improvements over the first version. Also MVC 3 is on the horizon and you want to hit the ground running.
I would also recommend keeping an eye on MVC 3 improvements if you're serious about getting up to speed in this space. A good blog to subscribe to is Phil Haack's Haacked. Phil is the project manager for MVC at Microsoft.
In terms of textbooks, the gold standard is Steven Sanderson's 'Pro ASP.Net MVC 2 Framework'. The first review on Amazon is from Scott Guthrie, a Microsoft VP, who raves about the book. He also has a competing book of his own. You can get the ebook from Apress here. Do a google search for Apress promo codes and you may save a few dollars.
Good luck.
Software is definitely not deterministic. Theories in programming are constantly developing and improving, which is what makes the field such a fast-paced and exciting place to work. Also, what may seem like the best approach to a software problem right now could be obsolete in a matter of months by a newer, improved technology.
Seems like every project I'm on uses a Model View Controller architecture, and that's how I roll my own projects. Is there an alternative? How else would one create an application that has persistent storage and a user interface?
MVC has been around for a while. It's a time tested and proven pattern. Many frameworks leverage the MVC Pattern. Martin Fowler has deconstructed the MVC into: Supervising Presenter and Passive View.
Architect Christopher Alexander said it best:
Each pattern describes a problem which
occurs over and over again in our
environment and then describes the
core of the solution to that problem,
in such a way that you can use this
solution a million times over, without
ever doing it the same way twice.
I'm not sure why you would want to move from MVC. Is there a problem you are encountering that MVC does not eloquently solve? To give you a better answer we need to know more about your problem domain.
Things to take into account when considering patterns/architecture: If you are building something with a Myspace type architecture you'll need a robust architecture (MVC). If you are creating a simple crud interface via the web - almost anything will do.
For .Net Web forms (I am assuming web, since you didn't say thick or web client) which is not MVC, it was a nightmare maintaining them. Web Forms applications that lived more that a couple years tended to become big balls of mud. Even then developers discovered ways to use MVC with web forms.
Ironically, the lack of MVC architecture in ASP.NET web forms was one of the driving complaints that lead to the development of ASP.Net MVC framework.
From experience if you don't use some MVCesk approach, your solutions become hard to maintain and bloated. These applications will die a slow painful death.
If your solutions are small one-off projects, the by all means throw something together. Heck there are tools that will generate everything from the screens to the data access layer. Whatever works to get the job done.
Classic CRUD apps built using tools like VB6 and Delphi have user interfaces, persistent storage and don't use MVC. Most of them used data aware controls linked directly to database fields
Couple of links comparing various MV* patterns which might be useful:WPF patterns : MVC, MVP or MVVM or…? & MVC, MVP and MVVM
Look into MVP model view presenter.
User interface is View and an application will always have a model and the bridge between the two is Controller. The whole MVC is nothing special as this is how the things will be always.
At the most you can get rid of Controller and have your view talk to your model but you loose the flexibility.
I've developed an alternative to ASP.NET MVC. You get the same loose coupling and separation of concerns but the difference is in how you go about building your projects.
I have a couple of videos on my blog, source code for the framework, a sample project and a few VS.NET add-ins (New Project item, New Builder and New View).
Builder for ASP.NET
Some key differentiating Features are
1. Templates are just html - no code mixed with templates
2. Templates are thus reusable across views and Web site designers can design templates in their design tool of choice
3. Strongly typed code (no ViewData and stuff) so you get intillisense, compile time checking, F12 navigation etc.
4. You build pages as compositions of views rather than an inside-out approach
5. View can be treated as "real" classes.
6. Everything is complied so no run-time compilation
Quite a few other differentiating factors as well.
In theory :
MVC is a proved technology and yada-yada-yada, and it is ideal for websites.
But in a real case:
A serious project that use MVC required a framework, hence you are following a framework with all their limiting and restrictions. So, at this point, the specific implementation of MVC is rule and not a simple "guideline".
Also MVC fail miserably for websites when it is about to connect to the model other than simple POST/GET, it fail with xml asynchronism and it fail with ajax. (*)
(*) exist some patch but a design must be clear and functional and if you need to "patch it" then it is neither clear nor functional.
Personally i think that the main problem with MVC is that it put so much effort in the Controller, where most project use not more that 5 lines for the controller part.
ps: Most "well done" MVC projects are 3-tier project.
ps2: MVC excluding some framework, is just a buzzterm, IS NOT A SERIOUS TERMINOLOGY and it is reflexed in the group of "interpretation of mvc".