I have been using IoC for a little while now and I am curious if I should use Microsoft's Unity framework (official name "Unity Application Block"). Does anyone have experience using it? So for I have been copying my IoC container code from project to project, but I think it would be better to using something standard. I think IoC can make a HUGE difference in keeping component based applications loosely coupled and therefore changeable but I am by no means an expert on IoC, so I am nervous to switch to a framework that will just paint me into a corner as a dependency I will one day want to walk away from.
I am using Unity with no real problems. I know a few ALT.NET type people warn against Unity but I really think that is just because of the history the MS P&P team have of writing bloatware. Unity is not yet bloated IMO and works well.
I took a look at the Unity Framework, but found it to be a little 'too big' for my needs (no, I can't really quantify that, it just seemed to require much more knowledge that other frameworks that I've been playing with... this was a while ago so it's possible that that's changed as Unity's been developed/refined).
My current IoC/Dependency Injection framework is Ninject. It's quick, fast, and I was able to go from reading the tutorials (about 10 minutes) to using it in a pre-existing project in about two hours.
If you're looking for a clean way to do dependency injection, I'd highly recommend checking it out.
I would say stick with the one you know until you feel confident with it and the whole concept. After what you'll have a better judgement to pick a framework which fullfill your needs.
I've played with CompositeWPF (aka Prism) - successor of Composite app block. From my experience Unity works much better as compared with previous version of ObjectBuilder. However it's up to you to evaluate IoC frameworks and choose one suited for your needs.
Unity tutorials & samples
Unity IoC Screencast
Related
I am about to start a project that I hope will some day require the capacity for scaling. The key question for me is: should I invest the effort to design for this eventuality now, or should I cross that bridge when I get there?
I know how these things go: everyone thinks their project might scale, but most projects never do.
Is there a set of best practices that will allow you to scale more easily at a later stage, while not investing too much in something that may never be needed?
Obviously I have no experience with scalable web sites. Currently I am leaning towards Scala / Play! / Akka. From what I can glean from the Akka website, it is very suitable for this kind of project (in that it provides a toolset that allows development on a single machine and scaling out to an arbitrary number of machines).
The project is a consumer-facing web site that involves some user interaction (comments, messages, voting etc.). The main focus is editorial, though. It's no Facebook :)
Not being experienced in any of these technologies (my experience mainly coming from PHP, AS3, Objective-C), I probably have a little too much on my plate right now. But then I am not going to go at it right away. I am aware that I need to get some experience using Scala and Play! first.
Any advice is greatly appreciated.
Start out by simply designing you model, build unit tests for that and then set your presentation layer on top of it. As long as your model is sensible, it will be easy to scale Play out to any number of machines. If you go for the build in JPA support, you can always deal with the question of which DB to go for.
You have larger things on your plate for the time being. So just make sure your design is consistent and sensible, then scaling will not be a problem.
You've got a head start by using a stateless web framework like Play! that won't get in the way when you need to scale. As ExxKA says, keep your model clean and sensible. This will help you keep the advantage of complexity.
Don't consider it a failure when you need to refactor your code - or even rewrite important parts of it. This is a natural part of a growing project, like a snake shedding its skin.
There are inevitably things that you'll learn in the process of writing the project, so don't try to anticipate them all right now.
I'm looking for a framework that is small and reliable and works in Flex 4.
I have some suggestions (but which should I choose):
Mate
swiz framework
robotlegs
Parsley is another choice that is well documented and can be used in a very lightweight manner. I'm partial to Robotlegs personally, as I like that it is very tiny as a framework and most of the broader functionality is provided by the community through extensions and add-ons.
For what it's worth, I've used Mate on several fairly large projects and must say it works quite well. I personally found it easier to learn and use than Cairngorm.
Property injection alone has made developing some of these projects a lot cleaner/smoother/faster. If I had to choose whether to use Mate on a project or go without a framework at all, I'd choose Mate every time.
I've been working for years on a project that is correspondingly huge. I've used Mate as the core framework of this project, and love it. I have found it to be just enough for what I need. I get the features I want without dramatically changing the design of my project. Contrast that with Cairgorm where your project becomes a complete frankenstein that doesn't remotely resemble how your project would look without it.
I have years of MVC experience (mostly Java Struts, shudder) and dependency injection experience (Spring, Guice, etc). As mentioned, I've also dealt with Cairgorm and found it to be one of the most painful experiences of my entire career. Out of the MVC and DI frameworks I've dealt with, Mate is the one I've enjoyed the most. I have no experience with Robotlegs or Swiz, so I can't directly compare them.
The only knock I would give against Mate is that it does not seem to be very actively maintained these days. However, I find it to be very bug free, and not in much need of maintenance. It isn't broke, and doesn't need much fixing.
All three are solid frameworks and I know very talented and seasoned developers who are partial to one or the other for various reasons.
All three have a dependency injection mechanism built into them and that is the sweet spot.
Mate is by far the most lightweight since it focuses primarily on dependency injection. Robotlegs and Swiz are a little more full featured and have more MVC components built into it.
So to that, I agree with Jason.
Has anyone implemented Orchard for a LOB application? If so, what was your experience? Would you recommend using it or another CMS or do you think it’s the wrong way to go?
To my experience, developing a custom LOB application around Orchard may be a good or bad idea. It all depends with what actually your are trying to achieve and most importantly what potential features/functionalities you want to leverage from the Orchard framework.
Personally speaking, I fell in love with the Orchard modularized architecture and simplicity of the backend design. I wanted to have all these features in my application and decided to write my application entirely on Orchard.
So, if you want to make same decisions I made, I should possibly warn you about the followings:
1 - You have got to understand the MVC internals pretty well since orchard has a huge amount of code written in this arena. If you are not that much of an expert in MVC, you will find yourself spending a lot of time figuring things out that you should.
2- Depending what type of application you want to develop, getting rid of some of the built-in modules may be necessary, even some of the core modules which may lead you into problems that are hard to fix.
3 - With this amount of customizations you make, any future release from Orchard will possibly break your code - and you may find yourself maintaining your own application framework and being unable to apply bug fixes and such. And mind you, Orchard is just a new framework, so expect a bunch of bug fixes, releases very soon.
Plus other possible ramifications, it is very important to weigh the pro and cons here before you make a final decision.
So, my advice is a follows:
If you think you can use Orchard without heavily customizing its internals, you will surely benefits a lot. On the other hand, if your project specifications are going to need you to make huge changes to the framework, then I wouldn't advice you to pursue this option.
In short, for a seriously big project - don't use Orchard.
Unfortunately, I am not aware of any other framework as well written as Orchard to recommend here.
Hope this helps!
My company needs to rewrite a large monolithic program, and I would want it written using a plugin type architecture. Currently the best solution appears to be MEF, but as it is a fairly 'new' thing I am warey of betting the future of my company (and my reputation) on it.
Does anyone have a feeling on how mature a solution MEF is ?
Thanks
Visual Studio's entire extension system is now built on MEF.
That is to say that Microsoft is Dog-fooding it (like they are doing with WPF).
Given that the framework developers themselves will be working with it, you can feel pretty confident that it is here to stay. However, as with any first release, you are almost guaranteed to have some growing pains when the next release comes around.
Personally, I would go for it. It is certainly better than the tightly-coupled-reflection-based alternative.
I don't think it is necessary to "bet on MEF". Your code should have very little dependencies on MEF.
You can use the technique of dependency injection to break up your monolithic application into components which have only a single responsibility, and which limit their knowledge of other components to abstractions. See this blog post by Nicholas Blumhardt for a nice overview of the type of relations that can exist between components.
Wiring the components together into an application can then be done with any dependency injection framework, or even manually. The component logic shouldn't need to be aware of the container - there might not even be a container.
In the case of MEF, you do need to add import/export attributes to your classes. However, you can still ignore those attributes and reuse those components without MEF, e.g. by using another DI framework like AutoFac.
It's a relatively new technology, so I'm not sure if it's exactly mature. I'm sure it will change quite a bit over the next several years, perhaps merging with other frameworks to better support IoC. That said, MS has a pretty good history of preserving backwards compatibility, so now that MEF is actually part of the Framework, I would consider the public interfaces stable.
That said, MEF might not actually be the right solution for your project. It depends on your extensibility needs and how large is 'large'. If you want to support true extensibility, including the possibility for third-party plugins, it has an enormous impact on your design responsibilities. It's much harder to make changes to the infrastructure as you now need to maintain very stable public interfaces. If you're really only after the IoC features, you're probably better off with a true IoC framework, which more clearly limits your design responsibility to support of your internal dependencies. If you're betting the future of the company, this is the bigger question, in my mind.
I'm planning on starting a new project, and am evaluating various web frameworks. There is one that I'm seriously considering, but I worry about its lasting power.
When choosing a web framework, what should I look for when deciding what to go with?
Here's what I have noticed with the framework I'm looking at:
Small community. There are only a few messages on the users list each day
No news on the "news" page since the previous release, over 6 months ago
No svn commits in the last 30 days
Good documentation, but wiki not updated since previous release
Most recent release still not in a maven repository
It is not the officially sanctioned Java EE framework, but I've seen several people mention it as a good solution in answers to various questions on Stack Overflow.
I'm not going to say which framework I'm looking at, because I don't want this to get into a framework war. I want to know what other aspects of the project I should look at in my evaluation of risk. This should apply to other areas besides just Java EE web, like ORM, etc.
I'll say that so-called "dead" projects are not that great a danger as long as the project itself is solid and you like it. The thing is that if the library or framework already does everything you can think you want, then it's not such a big deal. If you get a stable project up and running then you should be done thinking about the framework (done!) and focus only on your webapp. You shouldn't be required to update the framework itself with the latest release every month.
Personally, I think the most important point is that you find one that is intuitive to your project. What makes the most sense? MVC? Should each element in the URL be a separate object? How would interactivity (AJAX) work? It makes no sense to pick something just because it's an "industry standard" or because it's used by a lot of big-name sites. Maybe they chose it for needs entirely different from yours. Read the tutorials for each framework and be critical. If it doesn't gel with your way of thinking, or you have seen it done more elegantly, then move on. What you are considering here is the design and good design is tantamount for staying flexible and scalable. There's hundreds of web frameworks out there, old and new, in every language. You're bound to find half a dozen that works just the way you want to think in your project.
Points I consider mandatory:
Extensible through plug-ins: check if there's already plug-ins for various middleware tasks such as memcache, gzip, OpenID, AJAX goodness, etc.
Simplicity and modularity: the more complex, the steeper the learning curve and the less you can trust its stability; the more "locked" to specific technologies, the higher the chances that you'll end up with a chain around your ankle.
Database agnostic: can you use sqlite3 for development and then switch to your production DB by changing a single line of code or configuration?
Platform agnostic: can you run it on Apache, lighttpd, etc.? Could you port it to run in a cloud?
Template agnostic: can you switch out the template system? Let's say you hire dedicated designers and they really want to go with something else.
Documentation: I am not that strict if it's open-source, but there would need to be enough official documentation to enable me to fully understand how to write my own plug-ins, for example. Also look to see if there's source code of working sites using the same framework.
License and source code: do you have access to the source code and are you allowed to modify it? Consider if you can use it commercially! (Even if you have no current plans to do that currently.)
All in all: flexibility. If I am satisfied with all four points, I'm pretty much done. Notice how I didn't have anything about "deadness" in there? If the core design is good and there's easily installable plug-ins for doing every web-dev 3.0-beta buzzword thing you want to do, then I don't care if the last SVN commit was in 2006.
Here are the things I look for in a framework before I decide to use it for a production environment project:
Plenty of well laid out and written documentation. Bad documentation just means I'm wasting time trying to find how everything works. This is OK if I am playing around with some cool new micro framework or something else, but not when it's for a client.
A decently sized community so that you can ask questions, etc. A fun and active IRC channel is a big plus.
Constant iteration of the product. Are bugs being closed or opened on a daily/weekly basis? Probably a good sign.
I can go through the code of the framework and understand what's going on. Good framework code means that the projects longterm life has a better chance of success.
I enjoy working with it. If I play with it for a few hours and it's the worst time of my life, I sure as hell won't be using it for a client.
I can go on, but those are some primary ones off the top of my head.
Besides looking at the framework, you also need to consider a lot of things about yourself (and any other team members) when evaluating the risks:
If the framework is a new, immature, "bleeding-edge" framework, are you going to be willing and able to debug it and fix or work around whatever problems you encounter?
If there is a small community, you'll have to do a lot of this debugging and diagnosis yourself. Will you have time to do that and still meet whatever deadlines you may have?
Have you looked at the framework yourself to determine how good it is, or are you willing to rely on what others say about it? Why do you trust their judgment?
Why do you want to use this rather than the "officially sanctioned Java EE framework"? Is it a pragmatic reason, or just a desire to try something new?
If problems with the framework cause you to miss deadlines or deliver a poor product, how will you talk about it with your boss or customer?
All the signs you've cited could be bad news for your framework choice.
Another thing that I look for are books available at Amazon and such. If there's good documentation available, it means that authors believe it has traction and you'll be able to find users that know it.
The only saving grace I can think of is relative maturity. If the framework or open source component is mature, there's a chance that it does the job as written and doesn't require further extension.
There should still be a bug tracker with some evidence of activity, because no software is without bugs (except for mine). But it need not be a gusher of requests in that case.