This is really a "pardon my ignorance" question so apologies if it doesn't meet the requirements.
I want to develop a fairly simple database application. It will be desktop based and lightweight so I'm happy that SQLite will suffice. I have also decided upon Qt and pyside.
Looking through the mass of tutorials out there, I keep coming across sqlalchemy and exlixir (and Camelot). I am basically just wondering what advantages there are to using sqlalchemy (and elixir) over basic QSql in Qt? What would I be missing if I didn't use such a thing.
I know this is basic but before I can progress on my self-tuition process, I just want to get this clear in my head.
Basically, you have 3 options here.
QtSql
QtSql is a separate module in Qt for working with SQL databases.
Pros:
Integration with Qt may be easier
Cons:
Hard to learn
Was made for C++, requires some redundant code
Requires adding one more Qt module to your project
Documentation looks bad
sqlite3 module
This a module in Python standard library to work with SQLite databases.
Pros:
Very easy to use
Code is quite concise
No external dependencies
Cons:
You do have to write SQL queries
SQLAlchemy ORM
SQLAlchemy makes work with databases similar to work with usual classes.
Pros:
Object Relational Mapper: exposes an object-oriented interface and makes SQL queries for you
Once you've set up the table information, work with databases is pure joy
Cons:
Steep learning curve
Here's my conclusion:
If you are comfortable with writing SQL queries and don't have to do a lot of work with databases, use sqlite3. And if you don't mind spending some time to learn something awesome, go for SQLAlchemy.
About the other projects you've mentioned:
Elixir seems dead, and SQLAlchemy has its functionality built-in now, probably better.
Camelot is just weird... I wouldn't use it.
I'm in a similar situation... fairly early in the PyQt learning curve, looking to work on some database-related projects. I've ran across some of what sound like the same threads that you have... they talk about sqlalchemy, elixir, or Project Camelot in conjunction with PyQt4. None of them really seem to go into much detail as far as explicit benefits, though. Apparently its assumed that the benefits are inherently obvious to the reader ;) For the most part... what I've gathered is that once you get to a certain level of complexity regarding your project, you'll most likely have more or less written some of the basic abstractions for database handling using the applicable Qt4 objects anyways and that you'd be money/time ahead to just use sqlalchemy/elixir rather than 'roll your own'. Camelot takes that a bit further yet, from what I can tell (as a green horn myself).
Here's what I've decided, for the near future: I plan to work my way thru the first few basic projects, using the DB stuff provided by PyQt. After I'm comfortable with that, then I may go back and rework things using sqlalchemy, elixir, etc.
Related
So I'm new to node.js, javascript frameworks, and meteor.com. I'm trying to learn how to build social networks, and I'm naive/struggling to understand why Meteor.js (meteor.com) wouldn't be able to do all the great things you see now that twitter, facebook, instagram are doing?
There's the comet technology between client/server, authentication configs, asynchronous coding for scaling and performance, and built on top of node.js.
I'm trying to learn more about long polling, comet, gridFS or how files are stored, and in general things like replication sets, and sharding to help with performance (esp since Redhat has this openshift platform that we can build our own private clouds with).
I have some computer science background, but it seems like magic, so what am I missing? If you all could think of a few buzz words that make a social network tick that Meteor.js doesn't support, what would it be?
I hear things about parallel and concurrency (webworkers fixes that in part, no?), websockets, that high level languages like python or java are better off supporting. There's only one to learn my answers, and thats by doing, but thought someone could sway me one way or the other via this thread. Thanks!
This question encompasses a really broad idea and just focusing on using meteor alone would solve this issue. Here are a few points to consider:
I don't think this framework would be a good starting point to learn long-polling, gridFS, etc etc. Meteor aims to be a framework that tends to be more of an ecosystem of packages e.g. you can certainly roll your own aformentioned strategies -- however for dynamic updates, Meteor uses its own Data Delivery Protocol (DDP) supported/implemented by (surprise) a good bunch of core packages such as Spark.
Parallel processing and concurrency can be better off done using other languages, but why not with? Since Meteor is largely based on node.js, and node.js is really good with the aforementioned stuff plus it can play very well with other languages so you could integrate smoothly. Meteor doesn't really require you purely rely on it, as other languages would say the same thing. It's all in the general engineering / planning for your project. There are already lots of really good stuff out there that rely on Meteor, join in! don't be afraid. It all boils down to planning (and the courage/perseverance to pull it off, of course).
Right now, we cannot tell if Meteor would be incapable of the usual great stuff by gigantic websites. Sure, we can do live updates, (its own kind of) publish/subscribe patterns, and powerful stuff to boost development (look at the seven core concepts of meteor to best understand this). It is not impossible to replicate what is already out there, really. We can only say it with uncertainty at the moment mainly because.. (see next point)
The framework is so young! it's still at 0.6.x at the time of writing. Please take time to look at the Meteor Roadmap to see how things are going in terms of broader support for persistence/databases, performance considerations, and the official DDP specification.
I hope I have answered your enquiry (and more, I hope). I'm really excited for meteor myself as it could easily be the next big thing. We have a couple of (for-)production projects using Meteor as well, so you're getting direct insight from a person who has done quite a bit of hacking (and tons of research and first-hand experience) in Meteor. Not that i'm saying i'm an expert or so, it's just so much fun to work with Meteor and i'm totally not kidding you.
Hope this helps!
P.S.: Fair warning though, resources and documentation is really sparse at this point. I try to contribute to the community as much as I can about it (one of my starting points is here, on SO).
I spent some time to learn C++/CLI, I feel it is powerful .Net language specially in interoperability concept. I think it will be great step if this language will extend its interoperability to include asp.net, till now the recent version doesn't support asp. But I don't know if there is a plan to do that in future version. Is there any reason that made the last version of C++/CLI can not deal with asp like C# or VB?
C++/CLI was never meant as a general-purpose language. It pretty much exists just for interoperability purposes.
If you have a C/C++ library that you want to use in your .Net application (be it your own code or something like WinAPI), C++/CLI is a good way to either create a managed wrapper for that library or to completely write the whole application, if that's not that much work.
Other than that, you should probably use C# (I think it doesn't make much sense to learn VB.NET if you already know C++). Other alternatives are F# if you think your application would benefit from a functional style. Or IronPython (or IronRuby) if you think you would benefit from dynamic typing.
And of course, you can mix the languages if part of the application would be better in one of them and other part in different one.
Another reasons against using C++/CLI at all are its weak support in VS (no IntelliSense) and the ability of C# to interoperate with native DLLs using P/Invoke.
To reiterate, use C++/CLI if you need to interoperate with native DLLs or already written C/C++ code. For other tasks, you should probably use C#.
The Visual C++ compiler does not support partial class, that is, until C++/CX come along with the help of WinRT projection. The one-obj-file-per-cpp tradition is hard to break.
Without the partial class feature, form designers need to edit the same file you are working on. That means parsing a file with a lot of irrelevant text, dealing with macros, etc, and most importantly avoiding bugs that would replace your important code as designer-generated. I can't think of many teams want to deal with that, especially for small teams like the Settings editor.
Besides, C++ parsers are slower than those for simpler languages. For web designers, if switching to a similair language can get a faster designer and compiler, why not?
I'm not sure if there's any reason ASP.NET does not natively support C++ inline within aspx files besides the development team didn't think it was worth the cost (I'm assuming this is what you mean).
You should be able to implement code behinds in C++, however. This should get you 95% of the way there, although you'll still need to code your pages in C# or VB.NET.
http://www.codeproject.com/KB/mcpp/helloworldmc.aspx (not my article, just a reference)
I was reading these days about large projects implementation in python and Flex, and very often people praise the use of framework (like Cairngorm, PureMVC or others) over traditional OOP coding.
I think i dont really understand the advantage of using FW, which is the strong point over classic programming? how big should be the project in order to use FW? it is intended mainly for web-applications? or can be used for desktop apps as well?
hope, all these doubts dont sound stupid to you, i am not Computer engineer, just electronic, so my knowledge of sw architecture is very limited.
Br
Using a framework is not really any different from classic OOP programming.
When you write projects in a similar environment, you will probably see yourself writing a framework (or a set of tools) over and over again.
A framework is really just code reuse - instead of you writing the logic for managing a common task, someone else (or you) has written it already for you to use in your project.
A well designed framework will keep you focused on your task, rather than spending time solving problems that has been solved already.
I would add my 2 cents here, using a framework will also help a better organized collaborative environment too. Your team mates will get to know about the code easily if you are following a standard framework.
In enterprise applications using framework helps meeting the deadline and better code quiality.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I have been developing in asp.net since its existence (also classic asp before that) and also I have been using SQL server as my back-end database.
After serious consideration, I now want to change the language I use. Considering the OOP capabilities of the .NET platform, what other languages do you suggest that I start learning instead of ASP.NET and why?
Also what should I use as a database? I have no experience in databases other than the SQL Server.
Django would get my vote.
Like you, I'd been using ASPNET since its creation and then a job forced me to use PHP. Then another. And another. I got to the point where 90% of my time was spent doing PHP and I didn't want to split my time between two completely different work-flows so I just went with it.
PHP, as you may or may not be aware, is a complete scrotum of a language when compared against the relative beauty of languages like C# or even VB.NET. And it's not getting better any way soon. Development frameworks mean you have to upload half-a-million files for each project and it all just feels unneccessary.
So about two months ago I started to look into alternatives. I use Linux now so I bump into Python quite a lot of the time. It looks pretty enough. It's always pretty well formatted (by design) and it has fairly excellent OOP techniques and opportunities.
Then I learnt about the Django ORM so I thought I'd make a quick site with some basic interactive features. I made a secret santa website for my girlfriend's family. Multiple forms, authentication, listing and detail pages and a splash of AJAX. Took me (a complete uber-novice) two days to get functional and the rest of the week to beautify (I'm a slow designer).
Other benefits include its superb built-in caching, a community that really knows how to program stuff, pre-made, reusable apps that you can just plug into your site and go, and python's easy_install and pip that make getting modules so simple. Oh and unlike ASPNET, it'll run on any OS which can make for considerable savings for personal projects.
I've since ported the rest of my PHP sites (and those that I have to maintain) to it and I'm about to start porting over my ASPNET projects. I'm happy.
Databases are pretty much a non-issue in Django. You pick one that's right for the size of your project, plug it in and the ORM handles all the DBIO.
I use SQLite for small-to-medium projects and a MySQL cluster for large projects.
I would use PostgresSQL for your database. It is by far the most feature complete of the open source databases. Though MySQL seems to be regarded as the best for speed. If cost is no object then oracle is obviously a big player.
In terms of language Java is going to be your best bet for similarity to the .Net languages. It is strictly typed and OO like C#. And is widely used in large enterprises, much like .NET.
Of course if you are changing just for the sake of change then maybe its better to switch to something more different. Ruby and Python are the big dynamic languages these days and will offer a different perspective.
Ruby on Rails seems to be very nice choice. Only it is a bit too different and bit too weird. But seems to be most effective, too. RoR is database agnostic, so the choice of database is not about syntax. You don't need to think about which database you use when writing application. You just use RoRs methods to access database and it will automatically wire it to the DB engine.
Or go with PHP and MySQL, it is proven and widely spread. I myself was using MS SQL Server first and switched to MySQL without problems. PHP is a bit dirty language, but it is comfortable to use and well supported and documented, too. If you decide to go this way, try ZEND framework, it solves lots of things and makes writing web applications much easier.
Use Mono, it runs on Linux, Mac and Windows. It runs my ASP.NET program faster in Ubuntu than when it is running on my development machine(Windows XP's IIS, though I haven't yet compared the speed when running on Windows server)
Languages supported on Mono: C#, Java, Boo, Nemerle, VB.NET, PythonNet, IronPython, Oberon, PHP, Object Pascal, Cobra, Component Pascal, Delta Forth, DotLisp, #Smalltalk
For database, use PostgreSQL, it is dubbed as the Oracle of the opensource database. It has many features suitable for enterprise-type system.
http://www.mono-project.com/Main_Page
Why not take a look at ASP.Net MVC, you will capitalize on much of what you already know and is quite a bit different in its approach to websites. Just switching without a compelling reason or target in mind is probably not that useful, however it doesn't hurt to learn another language.
This site is built on ASP.Net MVC and Linq to SQL.
What is the reason for you leaving the .net scene?
A change of language may not fix the root cause.
I switched from LAMP to .net myself due to my job and then gradually in my hobby time to allow me to focus 100% on 1 language.
I switched from LAMP to .net myself due to my job and then gradually in my hobby time to allow me to focus 100% on 1 language.
You probably learned a few things from LAMP that you could apply to .NET. That's the best reason to explore other languages and frameworks.
Dynamic scripting languages can save considerable development time: no compilation, weak typing, and flexibility.
Personally, I love the flexibility of php. There are no abstract, inflexible, complex web controls to learn. I have complete control of my widgets because I can change the underlying code.
I didn't know php is still like a scrabbled scripting language... I don't want to go back to the old times...
No I need the shift to be as smooth as possible. From what I read, it seems ruby is going to be the choise... although Django seems interesting.
To be perfectly honest, the more I discover and experience in JavaScript / jQuery and DOM the less I use asp.net controls and related garbage on my pages. I have reached to a point where I know use ASP.NET for my project's back-end (objects and data classes to send and retrieve data) and standard HTML forms and controls on the front side, using jQuery for DOM manipulation and communication (thorugh ajax) with the server.
Having come to this point in my development career, I thought it would be a good idea to learn a new language that is faster than asp.net, that is not dependent on windows, and that is easier to learn.
I can then buy a macbook and relax :)
SQL Server Express has worked fine for me. I've used a lot of different databases with c#, but only mysql and binary files in production.
ASP.NET isn't a language. It's a framework upon which you can build web sites and web applications.
the reason is not job-centric.
Recently I realised I had enough of
bits-of-pieces that keeps me stuck
with microsoft. e.g. I want to buy a
MacBook but I can't since I need IIS
and VS etc.. (I know I can use windows
on a mac but what's the point)
Are you tired of Microsoft in general or ASP.NET specifically? Or is there a Cult you want to join that requires MacBook ownership? Or are you interested in LAMP or Java development? Do you still want to do web applications or are you more interested in desktop or mobile applications?
As far as databases are concerned, the most obvious alternative would be MySQL. Other options would be PostgreSQL or SQL Lite
I am creating a project called MPDA. It is a simple Dll and application that creates files that act as databases. It is aimed at .NET developers that want to use a database that does NOT impact on system performance on the system it is hosted on. Has no webside dependencies. If you have FTP access you can host it. No install required client or webside. Works on ANY platform with a file hosting ability. On drawback is it is accessible from .NET only.
One of the stated goals of the PureMVC framework is to avoid platform dependencies in order to be portable. Considering that because of language and API differences application code will always be heavily dependent on the platform, and that avoiding platform dependencies makes the framework reinvent the wheel and/or only provide a least-common-denominator feature set, in what way does the portability of the framework benefit me as an application developer?
I've worked with PureMVC. They're trying to implement their stuff in quite a lot of languages. You may be right about the least common denominator, but overall, it's not a bad framework, and I've seen a really nice AS3 app in PureMVC.
I don't think they're talking about portability in terms of porting actual code. The idea there is more that you're using a generalized MVC architecture, which you could apply to other projects and other languages.
They're trying to say that if you become familiar with the PureMVC pattern, you could potentially come into a new PureMVC codebase, even if it's another language, and you would already know the lay of the land.
You might also say that developers who develop good PureMVC skills are likely to develop good habits which will translate as they go from language to language. But then again, maybe not.. for the reasons you mentioned.
We've been using PureMVC on two projects now and in my opinion the attempted language-independence is quite a burden.
The promise of jumping straight in a project because the framework is already know does not seem relevant to me if the languages are not already pretty similar (C# to java would make sense, as3 to php not) -- I agree that it is useful to have known ways of solving things, but for that the 'plain' patterns are good enough.
However, I also don't really agree with the usage of the various patterns the project uses, so our choice to not use it on the next project might be related to both issues, and not just the attempt at language/platform independence.
PureMVC's portability will help you when you migrate to or reimplement in another language.
I can't count the number of platforms and languages I've written code for that are now extinct and for which, even if I still had the source code it would be mostly worthless and have to be rewritten from the ground up today, since the code was usually 100% platform specific.
But all application code need not be heavily dependent upon the platform. View components and services (the boundaries of your application) will necessarily be, but your application logic which is sandwiched between the boundaries need not be.
The scope of PureMVC is really quite narrow; merely to help you split your code into the three tiers proscribed by the MVC meta-pattern. There is no reason why this code has to be tied deeply to your platform in order to be optimal.
When it comes time to migrate, you'll appreciate that the framework actors and their roles, responsibilities and collaborations remain the same. This leaves you to deal with syntactic differences of the language, recreating the view components and services. At least you won't have to completely re-architect.
And for the case of reimplementing in a different language, imagine you're trying to capture a significant part of the mobile market with your app. The market is so fractured, you'll have to implement the same program on 2 or more of Windows Mobile, iPhone, Flash, and Java. Sure you'll probably have separate teams in charge of the apps, but why have a totally different architecture? With PureMVC, you could have a single architecture for all versions of your application.
-=Cliff>
PureMVC is the only real option for Flash Platform developers who choose not to use the Flex Framework. For certain projects the size cost of Flex is too expensive (it happens!).
I like to prototype in Flex and then rip it out and replace my views with custom components when the application is near completion. PureMVC makes this really easy to do with it's Mediator pattern. I'm not sure there is any other framework that would allow me this workflow.
Personally, I think PureMVC went too far with it's portability goals: I enjoy that fact that it works with Flash AND Flex (for the reasons mentioned above), but feel that it should have stopped there, and made use of the native Flash Player event architecture.
Are there examples of people using PureMVC to build and port applications across multiple platforms?
My company is building a Flex application that we may need to port to other platforms:
Silverlight (likely)
Mobile (maybe)
Desktop (maybe -- not just AIR!)
TV sets (maybe eventually)
I am considering PureMVC as a framework if it can ease porting and maintenance. I am curious to know if other people have ported a PureMVC app to a different platform and what their experience was with porting and then having development proceed in parallel for the app on multiple platforms.
Cheers,
Karthik
PureMVC does not rely on a platform for its internal workings (Flash Events etc).
So, while it does not make porting any easier per-say, it can assist simply by showing us its friendly and familiar face wherever we may choose to go ;-)