As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
My team and I are beginning to plan the development of a modular application which will likely multi-target WPF & Silverlight.
I personally have some experience using the older version of PRISM to build a composite Silverlight app using the MVVM pattern. We weren't familiar with MEF at the time for handling the various module dependencies, so we didn't use it.
We aren't married to any particular framework, but want to use one of the bigger players out there. As such we've begun to examine Caliburn/Caliburn Micro, Prism, MVVM Light and Reactive UI.
Most of what I've read for modularity suggests PRISM and MEF to handle that part of the process. As I'm still wrapping my head around some of this, I'm not sure if I'm missing some obvious options. I was able to find this article on Caliburn Micro and MEF.
Can anyone point me to similar articles using some of the other frameworks to compose a composite app similarly to the way PRSIM uses Regions, etc? Ideally, I'd like to limit the number of frameworks needed while providing maximum flexibility. We aren't averse to taking a "best of breed" approach and using for example MEF/PRISM to handle the compositing and MVVM Light for the View management, etc; but why use 2 when 1 will do?
One thing you should probably do first is isolate these into their appropriate buckets. I see this a lot where people will mix MVVM frameworks with application composition frameworks. Once you have them in the appropriate buckets you can start to pick one framework from each category and combine them into what you consider to be the best scenario.
Application Composition
Prism (using any IoC container: MEF, Unity, Ninject, Autofac, etc. There are a few things that make MVVM easier with Prism, but I wouldn't call it a fully featured MVVM framework... it's primarily a modular application composition framwork.)
MEF (MEF is actually able to do application composition out of the box. It's often dismissed as just an IoC framework, but it is deceptively powerful.)
MVVM Frameworks
ReactiveUI (my favorite)
Caliburn
Caliburn Micro
MVVM Light
This will help you make a decision, I think. You can pick and application composition technology you like and an MVVM framework you like and be off and running to the races.
As for articles, I don't have too many. There are a lot of good articles on application composition with Prism (that's pretty much its job), but here is a good article on application composition with MEF by itself:
http://blogs.microsoft.co.il/blogs/tomershamam/archive/2009/08/11/wpf-mef-declarative-composite-ui.aspx
You should also check out Glenn Block's series "Building HelloMEF" on his blog. I couldn't find a comprehensive list (he wasn't consistent with his tagging), but here is the "MEF" tag. Lots of good stuff here:
http://blogs.msdn.com/b/gblock/archive/tags/mef/default.aspx?PageIndex=1
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We are trying to port existing thick client to thin client. We are looking at the different technologies, We are trying out different options. We tried GXT as well as GWT in our sample excercises. Which one do you think we should go ahead with? Are there any other better frameworks?
It's several years I work with GWT (but not GXT). I'm using free version of SmartGWT which is a framework based on a google web toolkit (like GXT).
I personally think if you want (& you have enough reasons) to use GWT, then its a wise choice to use a framework above it such as GXT or SmartGWT or others. This frameworks provide a lot of abilities & ready widgets which make development progress so easy & fun, but they have also their own disadvantages, such as increasing your client side js code size, incompatibility with some browsers, execution overhead which may increase response time a little & so on.
Anyway, beside all weaknesses, I believe that it worth to use them & so I suggest you to USE a GWT-based framework, but before choosing one, take care about these notes:
development community, their activeness & speed of adapting with new releases of JDK, GWT & specially new versions of browsers & availability of samples, resources & discussion forums
the variety of provided widgets & ease of coding for developing new softwares
the ability to customize widgets
the ability to integrating with the other technologies & widgets from other similar frameworks
supported development IDEs
& finally the license & pricing
The decision of framework depends on your requirement.
The factors that may influence to selection of framework may vary based on how large product you are going to develop.
Factores mainly include,
The time for learning.
Supporting libraries/plugins.
Fearures Supported.
Development time.
Support forums.
As I have done some research with GWT and GXT as well.
Time to learn GWT is more.
GXT has more number of widgets.
see this .for performance of GWT vs GXT.
For a commercial and large product deveploment the decision to choose GWT,GXT depands on requirements.
There are lots of other frameworks.
vaadin
dwr
ZK
Apache Click
Apache Wicket
Apache Tapestry 5
Ariba Web
There are many web frameworks available apart from gwt and gxt. There is Vaadin, Dart and many more.
GWT is the foundation of gxt and vaadin. Which technology you want to use depends on your application requirements.
GWT is great in terms of performance but not so good with looks
GXT and Vaadin which are built on GWT provide more rich features, more widgets, good in terms of UI and lags in performance.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I want to start working on a project where I want to build a intranet website and mobile app for people working in my office for car pooling. The basic idea is that if anyone is interested in looking for someone to carpool with should make a posting of going from A to B at time X.People can then reply to it.
I've narrowed down my option to Scala+Lift+MongoDB or Node.JS+Redis/MongoDB+HTML5. I don't know which one is better or worse for the problem I have mentioned. Also looking at developing mobile apps for the same application where people can send carpool request over their phones.Looking for a stack which can complement the mobile development also.
I know there are various solutions for this, but I'm looking to learn something new and exciting and have fun while developing it.
The only requirement that influences the technology stack is "looking to learn something new and exciting and have fun while developing it" (just as broofa said).
However I have no idea how he came from that requirement to JavaScript.
Yes it is more marketable
Yes there are way more people that know it.
Yes you'll need it any way.
But is JavaScript in anyway interesting as a language? Not much I'd say. Any nice unique (or at least rare) concepts? To me it looks like programming in java, but not being allowed to use anything but Hashmaps + java.lang.*
Scala on the other hand combines functional and object oriented in an extremely interesting way. It has a strong type system which enables tricks that probably will make your head spin.
And even if you don't use the really fancy stuff you have a super powerful language to work with.
So if you want to learn: Go with Scala
The capabilities of the technology stack here are probably unimportant. Both Scala and Node will allow you to implement a web interface / HTML5-based application for mobile devices.
So it boils down to your other requirement, "learn something new and exciting". If you're not familiar with node or JavaScript, I'd suggest Node because ...
JS is a much more marketable skill than Scala (currently)
If you want other people to work on this code, more people know JS than Scala.
You are only learning one new language instead of two. (You have to learn JS in either case to implement the front end. With Node, that expertise carries over to the server as well.)
... and even if you are familiar with JS, working with Node will make you a much better JS developer.
My $.02. You should get somebody who knows something about Scala to chime in here however.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
What do you think about both?
I began reading a book about Catalyst, and found it pretty complex as compared to Dancer.
so now I'm giving Dancer a try, and it looks easier to learn and more "human friendly".
I think David's comment is very accurate and excellent. However, as someone who has done development in both but is not a developer on either perhaps I can be slightly more objective (and technical) in what the differences are.
Both frameworks provide a variation on the Web MVC paradigm.
Catalyst's main level of abstraction is the Controller. Catalyst expects you to break separate logic out into separate packages in some logical fashion (Login code goes here, Registration code goes there, Search functionality over here). This works incredibly well if you have a team of programmers since each of you can work on separate files and not step all over each other during merges. Catalyst provides a lot of tools for making the Controller logic extensible and flexible, I think the premier example of this is Chained actions which let you split up and build a complex flow for any given request. The downside is that it becomes very seductive to put your business logic into the Controllers and you end up with very fat logic in the Controllers where it (theoretically) belongs in the Model.
Dancer's main level of abstraction is the Route. My experience with Dancer is this leads to much smaller applications. Partly my experience here is tinged with the fact that I have dealt with several thousand line applications in Catalyst but I have yet to write a Dancer app that is longer than 200 lines (with a much smaller scope). I think however that this experience holds true. The push in Dancer is in keeping the Controller logic very thin because it doesn't have the same tools for managing complex behaviors there that Catalyst does.
Honestly I've enjoyed working in both of them. They both provide different opinions on what writing a web application is supposed to be. I would, given the time and inclination, recommend learning both ultimately.
This is a somewhat subjective question, but I'll try to give you an answer in an objective way. First things first, a disclaimer: I'm part of the Dancer development team, so my opinion should of course be considered somewhat biased :)
Catalyst is more widely used than Dancer, and so there's more community support behind it - if you were to look for contractors with experience working with either framework, say, you'd be more likely to find developers who've used Catalyst. So, if you're looking for commercial support, that would be a good reason to choose Catalyst.
Dancer is a younger project, and targeted more towards smaller projects, making getting up and running quick and easy, and trying to stay out of your way. That's not to say that Dancer isn't suitable for larger projects, however; the same habit of staying out of your way means you can organise your project in the way that suits you.
However, it has picked up a lot of support, and there's a growing community of helpful users and developers on IRC and the mailing list, and more and more useful plugins being released all the time. As with Catalyst, Dancer is designed so that you can pick and choose your preferred template engine, session storage backend etc, and it's easy to extend the framework by writing your own plugins if you need to.
For user testimonials to see what people say about Dancer, see the section at the bottom of the homepage on the new website: http://www.perldancer.org/
In the interests of showing other options, there's also Mojolicious, another modern Perl web framework which has been gaining in popularity lately.
Catalyst provides the same abstraction that Dancer does, Dancer's strength or rather Catalyst's weakness or rather Dancer's weakness is in how Catalyst forces the developer to adhere to Perl OO best practices and the MVC design pattern. After doing webapps for a while, this will all become apparent.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is LISP or something like Jess the best choice? I'm interested in writing a program that makes a suggestion based on users' answers. Computational considerations are not really a factor this is pretty much a pattern matching engine. Also I would like to make an app for this and put it up on the web.
UPDATE: I would like to put this up on a blog or website and let people use it from there. I guess my question then is there a particular inference engine that works with the .NET family, or PHP, or something to that effect? What are some of the pros and cons of each options etc.
Step 1. Pick an inference engine. There are many choices. Here's a list: http://en.wikipedia.org/wiki/Expert_system#Shells_or_Inference_Engine
Step 2. Use the language that interfaces with the inference engine.
You'll be much happier leveraging an inference engine for expert systems work.
I would like to put this up on a blog or website and let people use it from there
Trivial.
is there a particular inference engine that works with the .NET family, or PHP, or something to that effect?
Doesn't matter.
Here's the confusion. Your "web site" and your "inference application" have NOTHING to do with each other. Nothing.
Your web site can be done in any tool set you can find. It doesn't matter.
Your inference application can be done in any tool set you can find. It doesn't matter.
Your web site will invoke the inference application through any API that makes sense. The lowest common denominator in API's (the reason that none of these choices matter) is to do this.
Write your inference application as a stand-alone command line tool.
Write your web application to run the stand-alone tool, collect the output and turn the output into an HTML page.
Note that this multi-porocess implementation may be faster and make better use of multi-core processors. It forces the OS to manage the web server (Apache HTTPD, for example), the web application and the expert system as potentially three, separate, parallel processes.
You can also take a look at Prolog. SWI-Prolog (http://www.swi-prolog.org) is very complete and has an HTTP support library included (http://www.swi-prolog.org/pldoc/package/http.html). This paper might be helpful in using SWI-Prolog on the web ("SWI-Prolog and the web" http://dare.uva.nl/record/285350)
And, you can find a tutorial on building expert systems with prolog at: http://www.amzi.com/ExpertSystemsInProlog/
You will hear a lot of subjective opinions here, since few people have experience in more than one language writing expert systems.
I can recommend Common Lisp, as there is quite some literature and existing code available in this language, and it is a very powerful language and not too difficult to learn (read "Practical Common Lisp" by Peter Seibel). Of course, any new high level language requires some effort to learn. For the web application, you can use, e.g., Hunchentoot and CL-WHO, and there are a lot of database bindings (I like Postmodern and CL-SQLite).
I would suggest CLIPS and its .net port clipsnet
http://sourceforge.net/projects/clipsnet/
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Yesterday I was reading some articles in this site while I stumbled on an article about this two new IoC tools. Which one should I learn first? Is there some specification about which one should be used when?
Neither Castle.Windsor or Spring.NET are new.
Castle Windsor have been around since late 2004
Spring.NET have been around since early 2006
They are two comparable DI Containers that essentially aim at providing the same services, so you don't need to learn one before the other, and neither do you need to consult any kind of specification on when to use which one.
I've been using Castle Windsor for about half a year and am generally happy with it. Spring.NET I have yet to look at, but it looks like it is very closely tied to the configuration system and doesn't support programmatic registration, and if this is true, that would be a major drawback in my eyes.
Castle Windsor and Spring.NET are not the only DI Containers available for .NET. Here's a larger list:
Castle Windsor
Spring.NET
StructureMap
Unity
Ninject
autofac
I'm one of the committers to Castle project (which includes Windsor) so I may be biased, but.
Windsor is very extensible, allows you to tune and bend it to your needs. It provides nice fluent registration API so that you don't have to write ton of XML. There are also tons of extensions that you can use to integrate Windsor with other frameworks, like ORMs communication frameworks (WCF, NServiceBus) etc.
Plus it has a very active and responsive community, so if you have any questions, they'll get answered fairly quickly most of the time.
I guess both are better in terms of configuration. No much difference but both are better than Unity framework. Why the hell you need marshalbyrefobject association in dependency control. But if we compare spring.net and Castle Windsor both are good. But question comes which one is complete container framework.
Like we need Aspects for validation on Dependency. So winsor utility fail. I guess it’s stupid to compare String.net with Castle Windsor or anything like such because all are utilities and spring is complete container framework. And all folks who say it’s heavy please check memory leak issues with all. It’s not spring or Castle Windsor , it’s stupid way of writing code.
So finally answer is if you need just DI use Windsor but if you need complete framework for any solution use spring.net.