|
|
Let me guess and all start with: Have you met Ted?
|
|
|
|
|
It never gets old, specially when when Barney says that. 
|
|
|
|
|
|
Any opinions? It's a Dependency Injection / Inversion of Control framework, for those thinking, "Who the elephant cares about a castle?"
About to rewrite a legacy app (VB.NET/WinForms --> C#/WPF), and trying to decide whether to take the leap to DI/IoC... Seems like the right tool for the job (Lot of CRUD ops, some reporting, a few external libraries to integrate), but the only drawbacks I've found online are people saying it's a little harder to understand. No framework is perfect, so when I see something with no one whining about it, I start to think it's over-hyped.
Opinions? Worth it? Waste of time? Liquid Nitrogen?
|
|
|
|
|
Ian Shlasko wrote: Opinions? Worth it? Waste of time? Liquid Nitrogen?
Yes.
|
|
|
|
|
Oh good... If someone hadn't taken that opening, I would have lost all faith in the Lounge 
|
|
|
|
|
Ok, ok... How 'bout 'No'?
|
|
|
|
|
No one says "no" to Liquid Nitrogen!
|
|
|
|
|
|
|
Seems pretty straightforward to use, but hadn't seen Ninject before - That might be more useful. Just trying to see if the whole IoC/DI pattern is worth the time investment.
|
|
|
|
|
The limited look I gave it (a whiiiiile ago), it seemed like "The Architect's Choice"™: a little over-designed. As further down the thread, I'd go with Ninject.
--------------
TTFN - Kent
|
|
|
|
|
So CW is the big one that tries to do absolutely everything, while Ninject just does what's needed?
|
|
|
|
|
Yeah, that was my opinion of the two of them.
--------------
TTFN - Kent
|
|
|
|
|
So, you're still alive. Apart from appearing on Steam occasionally, you seemed kind of dead.
|
|
|
|
|
Yep, still alive. Was unemployed for about six months, and now I'm on the job again but busier than before. Not as much time to mess around on CP.
|
|
|
|
|
Without trying to sound controversial, DI in most cases is a complete waste of time and effort.
MVVM # - I did it My Way
___________________________________________
Man, you're a god. - walterhevedeich 26/05/2011
.\\axxx
(That's an 'M')
|
|
|
|
|
Most cases, perhaps. Trying to determine whether it's a good decision in THIS case.
|
|
|
|
|
Yeah - I've worked on a couple of systems of reasonable size where DI has been used. One using castle windsor.
I personally found it added more complexity and saved little if anything. We weren't using unit testing at the time, so it didn't help with that either.
It seemed to me to be one of those times when some dev has persuaded everyone to use the latest big thing and nobody really looks at the benefits for that application.
As i only used it on that one system it's difficult to be objective - maybe others have had more success.
MVVM # - I did it My Way
___________________________________________
Man, you're a god. - walterhevedeich 26/05/2011
.\\axxx
(That's an 'M')
|
|
|
|
|
I've not used CW, but I am currently working on an MVC project that uses Ninject. As far as DI/IoC, I'd say it has helped keep me on the right track. That is, I have to think things out ahead of time, and avoid writing a function in one view that I copy/paste into another view (or action). With the logic centralized into a repository, I can easily reuse that logic without taking the easy way out and writing sloppy/unmaintainable/hard to refactor code. I was also using it at the beginning of my project to create a "fake" repository that I used to code the views without doing the plumbing in the CMS to provide real data.
It also has other hypothetical benefits which I have not yet made use of. One being that I can test to code more easily. Another being that I can reuse the views for other projects (e.g., standard widgets). I could also easily swap out components (e.g., the data store) and do some central changes (e.g., optimize performance by caching some operations).
One cool use case is that you can use it to use debug code without worrying about it making its way to your production environment. For example, if you need to ensure your CSS/JavaScript files are never cached while debugging, you simply apply a query string to the file where it is referenced. In your real repository (the one you use with release builds), the cache-buster query string is empty. In your fake repository, the cache-buster changes with each page request. You can swap out other settings in a similar fashion to ensure the development process is quicker without having to worry about scrubbing your debug values/logic when deploying to production.
|
|
|
|
|
Hmm, I like the idea of it forcing better structure. I may be the only developer on this project, but I'm also not a morning person, so I can be sloppy at times. Component reuse is a plus too, but so far WPF's MVVM structure has made that pretty simple.
The last concern I have right now is that in terms of code structure, WPF and DI/IoC may be a little redundant. Different layouts both accomplishing the same goal. I might use some light DI/IoC for the model, and do the GUIs normally.
|
|
|
|
|
...but in this case[^] it's got to be worth a try...
The only instant messaging I do involves my middle finger.
English doesn't borrow from other languages.
English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
|
|
|
|
|
Shared.
speramus in juniperus
|
|
|
|
|
Liked and Shared! Always there for a good cause!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
