This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How do the major C# DI/IoC frameworks compare?
There being so many DI containers, I feel kind of lost. I'm new to the DI pattern.
I'm reading the book Dependency Injection in .NET and I've found DI to be incredible useful in improving a code base, making it loose coupled and more testable.
I now want to introduce a DI container for my dummy project, but there are just so many to choose from.
How am I supposed to choose between Castle Windsor, Unity, StructureMap, Spring.NET, Autofac, Ninject, Funq, LinFu, etc, etc?
I guess a coherent take would be to "just pick one" and start using it (since I figure they're pretty easily interchangeable, specially in the early stages), but I would like to make a more informed decision.
This is like buying a car. You might like a Toyota, but it's just 2.5L engine. You might like Ferrari, but it's too red. You might like Mazda, but your boss doesn't allow you to drive it. You might like Hummer, but then your colleagues would laugh at you. Mix the manufacturers to your taste, there's always going to be something missing for somebody or at some different moment.
My take is - first and foremost, DI is usually better then not having DI. Pick anything and you'll be better off. I'd pick something that:
Has good support in community (so you can get answers)
Has a good backing company behind it (so you don't get to rewrite your code when it goes bust)
Feels good to you (so you don't swear in front of the kids, not cool)
Is not an overkill for the project
Is not just DI, but offers an ecosystem of things that will reduce the time you spend on tasks that you know you can do, just not right now - and then you can focus on things that matter
Is used by a lot of people (so you know that many parts are also tested in real life and bugs filled)
Isn't 5 years old (such as that documentation says it is supported on Windows 98 or something)
My 2 cents - http://www.springframework.net/. I mean, their documentation contents page is like 20 pages long...
Or you just might want to look at some more answers to a similar question:
Which .NET Dependency Injection frameworks are worth looking into?
You can start with the builtin DependencyResolver in MVC3. Later you can easily upgrade to Enterprise Library Unity DI.
Brad Wilson had mentioned a series of posts on How to use DI in MVC3.
My stance is, look at a few - you got the excellent "Dependency Injection in .NET" book already (to that list I would add Ninject, which unfortunately is not covered in the book) - and pick one of them that you understand the best and like the syntax. To get started with advanced features are not really important, just that you do start.
Once you have a IoC container, replacing it should be mostly trivial since all your changes will be in one spot - the aggregate root - and not spread out all over your code base. Using an IoC container will also force you to design for dependency injection if you have not already, that will be the much bigger impact on your projects.
I've been using Ninject and Unity. When you add Unity MVC to Unity, then the code reminds me of the Ninject code.
Both are very easy to implement. Both allow substitution of being config file centric with a launcher class centricity.
I suggest create a 2 hour project, and implement it in each of the ioc di frameworks, and decide by experience which one you like. However, if you do this without looking at other features you may find that you missed something. So do look at periferal features, such as 3rd party support.
In addition to the other great comments - if you install the Unity.MVC3 package, just beware you have to use HierarchicalLifetimeManager if you want your objects disposed with each request. Its worked great but I think you'll find in most cases all the major ones are quite nice.
The question for you is to find one that fits into your environment. Some places allow open source, some dont and in those cases Unity wins out.
The most developed DI container for .NET is Managed Extensibility Framework (MEF) and I strongly recommend to use it. MEF is fast, easy and maintainable across the team together with a perfect learning curve.
Related
I've been reading up on several PHP frameworks, and reduced my candidates to CodeIgniter and Symfony (I know there are many more). Strongly leaning towards CodeIgniter, but have not 100% decided quite yet.
I'm not looking for a general "CodeIgniter vs Symfony" discussion.
One thing keeps coming up in comparisons: people say Symfony is for "advanced" coders and "bigger" sites; CodeIgniter is for "beginner" coders and "smaller" sites. But I have yet to see any technical proof of this. Everything I'm seeing about CodeIgniter feels right.
Can anyone explain structurally and technically where people are basing these statements on?
I want to understand all I can. Once I make a decision, I want to focus my attention on one framework.
Thanks,
Matthew
The biggest technical difference between CodeIgniter and Symfony (ver 1 and 2) is that Symfony is much easier to extend. This is especially true with Symfony2; you can replace entire parts of the framework as you see fit with custom code, or code from other libraries. You can even take any number of core components from Symfony2, and build your own framework on top of it. But, it's important to note that because Symfony is so 'advanced', it has a higher learning curve.
Here's how I see it: CodeIgniter is great when you have a small(ish) project that falls in the category of problems CodeIgniter is meant to solve. But when you want to do something your way, not CodeIgniter's way, you're going to have to fight the framework, which is never fun.
On the other hand if you're working on a Symfony2 project and want to do something your way, you can. It won't necessarily be quick, but it is possible. To me, that's the most important thing - you need to be able to make the framework do what you want it to do.
If you have time, read through the Symfony docs and cookbook - they should give you an idea of what Symfony is capable of and how to customize and extend it.
Everything I'm seeing about CodeIgniter feels right.
Then go with CodeIgniter. The most important thing is that you're comfortable with the framework/toolset. If you complete a project and find that it's lacking in features, you can always check out other frameworks.
I would recommend starting without a framework. If you have been programming awhile and are comfortable with concepts like MVC and why you might implement your code in this pattern, then frameworks start to make more sense.
Frameworks are good for larger projects where there are many programmers and you need a consistent method of building application layers, like MVC. The framework will likely provide some mechanism for object management and a consistent way for you to build application events (controller) and to separate the view logic from the model logic.
My PHP apps have been smaller, so I have not used any frameworks. When I used to code in Coldfusion, on larger apps, I used MachII, Model-glue, Fusebox and ColdBox. Each was good at something, each promoted consistency, but each had a lot of overhead and often times felt like it was in the way. I saw some developers get stuck because of the framework.
I did not start using any CF frameworks until I had build smaller apps without one.
If you like CodeIgniter better, for whatever your reasons, go with it.
CodeIgniter, because of the gentle learning curve and the great documentation. Give other frameworks a go if you ever feel you outgrow CI, which you may never do.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm inheriting a bunch of programs at work where the original author used Microsoft Visual Studio's data components (where a dataset, data adaptor, etc) are creating inside the design environment (from the toolbox or using wizards). This yields some semi-tailored (specialized for the data) classes, and also puts the SQL code into designer generated classes.
This is not how I'm used to doing things (I've always preferred to either unambiguously have a dataset, or create my own specialized class to hold the data and hide the complexity of the underlying data layer).
Does anyone have some good insight or links discussing the pros and cons of using Visual Studio data components?
(A side note, the original author also didn't comment very thoroughly and wrote, for my tastes, a bit too much "clever" code that is not easily interpreted, so I'm not inclined to think he knows any better than I.)
I suppose another way of asking is this: Does using the data designer components result in code that is "following best practices" and is maintainable, etc? It doesn't seem so to me, but I'm looking for input from experts.
[EDIT: Added some more context for clarification of intent]
If I'm right (and it looks like I am) about using designer components really being best suited for prototypes, etc, then I'm going to have to go have some tough conversations with the original developers and my manager. So I'd like to add more emphasis on "links discussing pros and cons" part of my question... I'm looking for something substantial I can use to support my claims that this style of development / code isn't the most appropriate for production use... Thanks.
In general visual components are for throwaway applications, POC's and spike applications, i.e. prototyping. This is for a couple of reasons; they are very quick to get together but a complete nightmare to maintain. I'm unsure of the size of your application but if it were me I would be arguing that in it's current form the cost of ownership will increase with time and therefore would look to more of a DDD style of development. Bin the data layer and replace it with a good solid ORM; NHibernate(preferred) or Entity Framework 4 (easier to get into). Drop that 'clever code' and start using the Kiss, Yagni, dry mantra. It might be difficult to get them to see the light but once it starts costing less they'll love you for it ;)
If you want some more reading in this area look at the following:
Skill Matter are a training facility that run open session and loads of podcast you can watch
A good book for both Dev's and managers to read is Ship IT, it looks at good project practices. As does anything on the pragmatic bookshelf
Martin Fowlers' blog for all thing DDD
Ayende's blog is great place for all things NHibernate
stackoverflow.com, this place rocks
VS data components purpose is rapid application development. From this point of view you can see its pros and cons:
pros: fast development, do not require much coding and knowledge. Good for small applications which will not be changed in a future.
cons: breaks Layer application design logic (add here all pros of such design) combining all in one file.
As a result almost impossible to replace datasource dynamically. Makes more complicated large application support. DI, TDD - it something mysterious using it.
Actually it's a very wide question.
I'd recommend to read more about N-tier application development and Test Driven Development
Hope this help
I wouldn't even go so far as to say that the designer DB components are good for POCs or prototyping. Those components are in Visual Studio primarily as a sales pitch for the framework, so that Microsoft can say "wow, look how easy it is to create a data-driven application with .NET!" They should have been removed years ago, IMHO.
However, don't confuse the designer components with ADO.NET (i.e. DataTables, DataSets, DataReaders, DataAdapters etc.) itself. Since the app you've inherited was built around the designer components, that means that it was also fundamentally built around the ADO.NET components. You can (and should) get rid of the designer components, but you shouldn't necessarily get rid of ADO.NET as well.
I personally think you are definitely on the right track, BUT imho it really depends on what you already have and what the plans are for the future of the product.
I have seen production code that uses just as you are talking about and works fine, and is somewhat easily maintainable.
There are even some great drop in modules from very large companies such as Telerik that fall into the same category of development that you are talking about.
I think what really is an important factor to your employer is: what can you use to get the job done in the fastest most efficient way. I would say that in general though, the "drag and drop" tools straight out of the box are not very good for long term enterprise level applications.
Here is an article by Charles Petzold that may provide more "expert" credential information for you.
http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I am taking over a lot of the ColdFusion stuff that is lingering at our shop and they are insistent it stay on ColdFusion and that new projects in this area MUST be done in CF - basically this part is non-negotiable. I am not very experienced in CF (haven't touched it since 2003) so most of my development has been in .Net, MVC, C#, Linq-to-SQL in the past 4-5 years.
I was doing some looking around for a MVC framework that I could relate my Asp.Net MVC experience to and hopefully an integrated ORM (I am stuck using CF 8 at least for a while). I have found a few like Model-and-glue, Mach II and Coldbox etc. but I don't really know where to start and wanted to get some opinions on the advantages, disadvantages, etc. of each of them from people who use them.
I know that I will need to do an extensive brushing-up (pretty much re-learning) of CFML, so I don't need to be told that - I am looking into the future here.
Could you please share any information you have on CF MVC Frameworks to help me choose which one will be best for me? Thank you.
Seeing you are NEW to ColdFusion what I would do is pick ONE FRAMEWORK and stick to it. At first it will be hard you will have problems and you will be tempted to drop the Framework you have chosen but don't do it. After you have mastered one framework then you can learn the others.
CF Wheels
ColdBox * * * (Nice Documentation)
FarCry
Framework/1 * * (simple LIGHT framework)
FuseBox
ModelGlue
Mach-II
Most of these you can add
ColdSpring
Reactor
Transfer
An introduction to ColdFusion frameworks at Adobe.com
Most important is to remember we all have our opinions but there is NO real proof what is best. You can even NOT use a actual framework and just code carefully in MVC.
The stuff you are currently maintaining
I would pick ColdBox, ModelGlue or Framework/1.
ColdBox provides a little Code Generation and Framework/1 is very light so less to learn.
I've been using CFWheels for a couple of years and I've not found a better framework. It's inspired by Ruby on Rails and is very easy to learn with great docs and a very active community.
www.cfwheels.org
I teach a course in ColdFusion and use Sean Corfield's Framework/1 in the classroom. It's lightweight and has a very gentle learning curve, which makes it especially good for transitioning existing codebases. But at the same time, it's easy for a team of developers to work with and can scale to large apps. It's the framework that feels least like a framework and most like natural code, to me anyway.
http://github.com/seancorfield/fw1/
I wanted to give a +1 for cfwheels.
Since 2003, I've used Mach II, ColdBox, Fusebox, and Model-Glue for various projects. All had their pros and cons (Fusebox is the only one I'd avoid now) but, with a recent project, I decided to try CFWheels.
Using Wheels has been a blast. I've had a great time developing a site for some friends in my small town who own and operate an Ice Climbing and Guiding site ([www.ourayclimbing.com]). Nice SES URLs, runs great on Adobe CF and Railo, the admin was insanely easy to get going with the Scaffolding plugin, convention over configuration (which I love :)), etc.
In any case, if you stick with the major players (ColdBox, CFWheels, Mach II or Model-Glue), I think you'll be pleasantly surprised at what CF can offer you.
It has to be coldbox really.
It has excellent documentation on the site, and also has a book which has been brilliantly written to cover many aspects about object orientated programming, amongst other topics. Honestly, really impressed by the book, more than I was expecting.
What I like about the framework is that it uses coldfusion code in its handlers, when I picked it up I think the other frameworks where using xml...not sure if this has changed.
The framework is easy to pick up if you are knowledgeable on CFCs, and has several useful features for building sites. PLugins, Debug toolbar, URL rooting for "pretty URLS"..
I cant speak highly enough of the framework..
Theres also a really helpful community here who respond to all my questions really promptly.
I'd suggest checking out Mach-II. It's used on numerous extremely high-profile, high-traffic sites and has been for years. This blog post is a bit old at this point but still has some great info in it in terms of Mach-II in general as well as who uses Mach-II.
It's under very active development (don't let the lower version numbers compared with other frameworks fool you) with version 1.9 just around the corner and big plans for 2.0.
Big features of Mach-II include sophisticated caching and logging functionality, a very nice dashboard for helping with development and monitoring of your applications, a rich form tag library complete with data binding, and tons more.
I'd go with either CFWheels or FW/1. Both are very easy to use for those new to CF frameworks (I still count myself in that group) and don't have nearly as steep a learning curve as some others. Coldbox looks amazingly powerful, but I had a hard time getting my head around it.
You might also like my SOS and COOP frameworks. We are in the process of creating better public docs. It will likely be more like the code you are used to than other options.
You could also look at ColdBox. http://www.coldbox.org/
Loads of documentation and loads of features.
There's also Farcry Core Framework http://www.farcrycore.org/
It has to be said that you'll need to make your own mind up which framework you like best or whether to build one of your own. It really depends on what you want out of the framework.
In terms of ORM for ColdFusion 8 you have Transfer ORM (http://www.transfer-orm.com) and Reactor (http://www.reactorframework.org/)
Though, given that ColdFusion is java application on top of a java server, there is no reason why you couldn't go ahead and use Hibernate (http://www.hibernate.org/) ColdFusion 9 does make using hibernate much easier, but you're stuck on 8 for the moment.
Everything is negotiable. Rewriting the CF apps in Rails 3 would be the strongest approach.
Languages and frameworks built on principles - Ruby/Rails 3 (and other Ruby frameworks), Python/Django 1.2 (and other Python frameworks), ASP.NET MVC 2 - are generally speaking the best thing to use.
ColdFusion and ColdFusion frameworks do not compare because ColdFusion as a language and as a library is hacked together at random and the ColdFusion frameworks (ColdBox, FW/1, Model-Glue, CFWheels, Mach II) can only do so much to smooth that over. For example: CF scopes, lack of closures, lack of loadable classes/components (you can instantiate a component, but not load the component as such), awkward arguments handling, mappings, lack of real applications, lack of delegates and closures, and convenient but non-rigorous approaches to most aspects of the language and library. In comparison, the other languages listed offer rigor plus sugar atop the rigor.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm facing developing a new web app in the future and I'm wondering how to decide what framework to use. I've settled on Python as my language of choice. But there are still may frameworks to choose from! More generally how do you choose between different similar technologies that are still in the works as the latest round of web frameworks are? I'm curious what your process is for deciding on technologies you've never used.
Recognize that no choice is perfect -- or even very good.
No matter what you choose, someone will have a suggestion that -- they claim -- is better.
No matter what you choose, some part of your tech. stack will fail to live up to your expectations.
The most important thing is "shared nothing" so that the components can be replaced.
After that, the next most important thing is automatically-generated features to reduce or prevent programming.
Look at Django. Lots of automatic admin features make life very pleasant.
There are a number of things you can do:
Download the frameworks and build something similar with them for comparison.
Look for comparisons by other people, but attempt to understand the bias of the reviewer.
Observe the community at work, see what people are building and the issues they run into when using the technology. Forums, blogs, mailing list etc are good places to check out.
Go to conferences and meet like minded developers interested.
You can also take the approach of using stable versions rather than alpha bits. After a while you might move closer the bleeding edge. People associated with the project in question are generally more biased than those approaching from other platforms, be careful who you trust.
Consider the impact of using a bleeding edge framework versus an established one. Sometimes it's important to your customers that you are on one perceived as stable. At other times this doesn't matter. How comfortable are you with fixing the framework itself? Great developers will learn the internals, or at least know enough to keep things moving whilst a bug is sent to the framework mailing list etc.
Consider some general best practices in building abstractions and reusable code on the python platform. You may be able to save yourself some work in moving to another platform. However, don't be a reuse junkie as this can limit the effectiveness of your use of the framework. The 37Signals guys are right when they talk about extracting frameworks from working code rather than building frameworks from scratch.
I know this is an old posting, but I am in a similar situation (again) and I think there are other people who may want to look for different opinions, and hear of (somewhat) successful experiences.
Since baudtack mentioned Python, I will try to answer this along the lines of my experiences using Python. Here is what has been working for me:
determine the scope of your project - outlining what your application is supposed to be able to do without introducing any programming or design notes will clarify your goals greatly
determine how you would like to work with your code, stack and data:
a. what sort of programming paradigm do you want to work with? i.e. object-oriented, functional, etc. do you want to play to your programming style or do you want to follow somebody else's programming style?
b. use semantic web or not? do you want greater control over URIs and their design? (I found web.py great for this by the way - It is my choice to create REST APIs in Python)
c. do you want to be trapped by framework requirements, or do you want a better separation of the application from the web component, i.e. use a framework to utilize your application as a set of modules, for example. My problem with Django was that I ended up not programming Python, but having to learn more Django than I needed to. If that works for you, then that is the way to go.
d. data stores... some sort of SQL vs. non RDBMS (xml databases like eXist-db with full xquery support) vs. OODBMS vs. a combination of the above? how complicated do you need this to be? how much control/separation do you need to have over how data gets stored and recalled in your application?
e. testing: unit tests... thank goodness for python! if your web app has the potential to grow (as they often do), having a sane and coherent testing platform to begin with will help out a lot in the future - I wish I had learned about this earlier on. oh well... better late than never.
f. how much control over the server do you need? hosting considerations? how much control over an Apache instance do you need to have? OS specific needs? I found that using shared hosting providers like Webfaction has been great. I eventually found I needed greater needs for flexibility and bandwidth. In other words, what can you get for your budget? If you have USD50 to spend each month, it may be better to consider a virtual hosting solution like Linode....
Finally, I echo S.Lott's sentiments that no choice for a solution is perfect, and are subject to obsolescence.
Experience trumps hearsay. I've found that prototyping is a huge help. Make a prototype that uses the features you expect to be the most important for various frameworks. This helps route out any features that may not work "as advertised."
In general though, kudos for being willing to look at new technologies.
I have a set of criteria in different categories:
Activity & Documentation
Is there an active user base?
Is there an active development base?
Is the support responsive and information accessible?
Are there user and development guides and reference material?
These are essential, there needs to be traceability of all of these to build confidence in the solution.
Ease of use
Are basic features easy and complex features possible? I typically give a new framework a test drive and try to roll out a set of use cases to see how intuitive the framework is to use.
Is installation intuitive and simple for a local/dev installation and production deployment?
How is it backed up and upgraded?
What is the effort and UX for implementing a "Hello World" type blog post, static page, menu item, and plugin?
How are versions dealt with for the core & plugins?
Example (on the topic of Automated Testing/Continuous Integration solutions)
Several years ago I evaluated several Automated Testing solution. At the time Jenkins and TeamCity were front runners and in the end I chose TeamCity because of the UX, active user & development base and quality of accessible documentation.
Example (CMS for a blog)
This criteria is also why I prefer to use Wordpress over other options. While wordpress has its shortcomings, the user and development base is strong and active which leads to a software architecture with more potential to evolve over time and maintain its relevance and a development community that provides quality plugins and themes to choose from.
Right now I'm not sure...
I'd say yes. I'm using it. I know for a fact that Universal are using it on some of their (thousands of) sites. I will add some caveats, however:
There are serious problems with setting it up, especially if you want to debug into the libraries.
The helper functions favour prototype, as opposed to the more modern jQuery. This is changing rapidly, however.
The documentation is a bit chaotic, again the Castle Team are working on that.
I'm not guaranteeing every last "out-there" feature works, but the point of the system is actually to keep it simple.
Compared to vanilla ASP.NET, it's an absolute joy. I assure you that you won't miss viewstate.
We have been building a fairly large application with it for the past year and a half. Its been nice not to have to deal with the old ASP/Page based model and use the better Model/View/Controller design pattern.
To get the new stuff you really need to work off the trunk of development because they don't do releases very often. We have a lot of tests that get the framework involved so when an update in the framework breaks something we depend on we know about it immediately.
If you have to work in .NET this beats the heck out of the alternatives.
There is an overview on the monorail forum: http://forum.castleproject.org/viewforum.php?f=6
I'm using it for an application and haven't had any big issues with it.
The biggest problem is indeed find good documentation and examples.
I've had no problems setting it up. Julian, I don't think it is constructive to say things like "serious problems" without any further clarification or example.
Debugging into the libraries is trivial. Because it's open source, you can debug into the whole thing.
I've been using MonoRail for production for ages on many projects, as an employee, as an indie contractor, and for non-work related sites.
I know I'm biased on that, however I can whole heartedly promise that my positive usage experience is what lured me into contributing to the project, not the other way around.