I'm working on an IT School project, so I'm gonna explain what I'm doing. I am designing a Telemarketing Campaign Creator. The MySQL Schema and database are correctly created but I have several problems and doubts.
I'm using Zend 2 Skeleton as my start point and I'm friendly with MVC programming method, so my doubt is how to start for implementing the models from my MySQL DB for my project.
Is there a methos to generate automatically the models?
Thanks for all! =D
P.S: I'm programming under Zend Studio 10.
If you're starting from scratch with Doctrine2, I would strongly advise you to come at it the other way around: Define your entities in doctrine, and use the doctrine CLI to generate and update your MySQL schema.
Remember, with Doctrine2, your Entities (which are 'just plain php objects') are first-class citizens. Database schema is just an implementation detail.
Once you get the hang of this workflow, it's incredibly productive. When the need arises, you can pull in the doctrine migrations library, and use it to easily manage schema changes over time.
Related
I am looking for tutorial or sample for Dapper using token based authentication in web api 2. I appreciate if anyone can suggest where to start, I have found tutorial in http://www.c-sharpcorner.com/UploadFile/ff2f08/token-based-authentication-using-Asp-Net-web-api-owin-and-i/ but the sample is using EF and I havent tried using EF, but dapper also I am using MySQL for my database. Thanks in advance and good day.
Dapper is a very different tool to EF (which is the DbContext described in your step 3 / step 4). It simply will not be compatible with those steps, and isn't designed to be used with those steps.
But here's the thing: dapper is just a tool. EF is just a tool. It is ok to use more than one tool. If it suits your purposes, then use EF to do one set of jobs (for example, to help you use a particular library that is designed with that in mind), and use another tool (such as dapper) elsewhere in the same project. That's OK. No one will mind.
If you really really don't want to use EF at all, then you'll need to find out everything that the library needs to support what you are doing, and implement it manually. If the library is designed around IQueryable<T> etc, then this may be very difficult.
I've recently started to play around with ASP.net MVC3 and the Entity Framework. I followed tutorials (code, model and database first) and I liked alot of the automagical things happening.
BUT (always a but...), it seem to me that the whole "system" is very much constructed for someone hosting the whole thing by themselves with total control. I'm trying to understand how it can be useful to me in my hobby projects and self learning and so far I've failed.
What I'm getting at is this: I have a pretty regular web hotel, I own a couple of domains there. But I only have 1 MS SQL database. And it seems which every way I go with code, model or database first my sites/projects/tests fight eachother in that database - dropping eachothers tables.
On the web hotel I have to use a package from NuGet so that only tables are being created on model change - no database dropping allowed. But tables that not exist in one sites project are being dropped and conflicts arrise.
Am I missing something or did they really not construct the framework for people like me?
If I had a MS SQL database dedicated for each site I want to work on it would work of course but since that is an extra service it will get very expensive. And my projects are very tiny at this pont so having them share a database is no problem performance-wise.
Can anyone advice me, say what point I'm missing or point me in the right direction?
Thanks in advance!
It sounds like you're using the code-first variety of EF. Try the database-first variety and generate your model from the database, rather than vice versa.
I don't really plan on using active record or any of the built in database constructs native to CodeIgniter for database access. I have Oracle, SQL Server, and others. I want to use PHP PDO (unless anyone thinks that's bad) because of the universal aspect of it.
I mainly want CI because of some of the built in libraries and MVC. I also like that it is small and easy to work with.
2.x if it matters.
I did see other questions but none exactly about databases.
Thanks.
edit: It's not that I don't think CI and PHP can take it with large websites. This is solely about using multiple databases of varying companies. I have mostly seen MySQL used with it. I know I can use other databases but again, I don't know if it is more trouble than worth or what.
MySQL is the default just because of how widely-adopted it is, especially in the PHP world. Almost everyone has a *AMP stack to work on so it ends up being the main driver used in almost every example out there.
If you're not planning on using the database class, then it really doesn't matter what type of database you are using, just don't load the class. You can still use routing, helpers, libraries, and other CI features.
So yes, I do think it is suitable for your purposes.
CodeIgniter was built with the idea of being the framework closest to native PHP that doesn't tell you what to do. The entire framework is modular and you are not required to use any single component.
Yes, it is absolutely suited to what you are doing. You can plug and play whatever DB driver you want and CI will not complain one bit.
I think CI is more suited for this role than any other of the 'big' frameworks.
A question of ColdFusion ORM
We are using ColdFusion 9 for the past 6 months and while we've used some of the new features, ORM is something we've avoided because we usually work on the same very large website. Over the years we've used Apache OBJ but then we moved back to CF and used our own DAO objects generated from tables to handle basic CRUD. These objects are basic and need to be regenerated manually for schema changes and do not model table relationships at all. To supplement these we have a set of gateway classes for multi-table queries. While all this is very bespoke, these DAOs and gateways do, however, give us great control over the SQL we execute, for example using locking hints and optimiser hints. Our site is busy but our database is very efficient.
So much for the history lesson: the point of this is that we have a new site upcoming soon that will be written from scratch to handle financial transactions. We would normally use our aforementioned DAO objects to handle CRUD and then the usual set of gateway objects for multi-table joins but I thought we might investigate using baked-in CF ORM...
So with that in mind, I'd love to hear of the lessons, tips and tricks others might have to share in regard to using ORM on a busy financial site. For example:
What's the best way to flush your SQL ? What tips do you have for transactional ORM? How do you setup development and live sites for ORM? What about HQL? When should we just do the SQL ourselves by hand?!
Thanks in advance!
Short answer, YES! go for ORM!!!
What's the best way to flush your SQL ?
ormflush()
What tips do you have for transactional ORM?
<cftransaction> or transaction {} in CFScript works fine, and even work across DSN's, much improved in 9.0.1! watch http://tv.adobe.com/watch/max-2010-develop/coldfusion-undocumented/
How do you setup development and live sites for ORM?
same as without ORM, but you may look into this.ormSettings.dbCreate if u mean the DB creation part
What about HQL?
What about it? :) Use it when u want an array of objects, but nothing stopping you from using the good old <cfquery>
When should we just do the SQL ourselves by hand?!
When you feel like HQL doesn't do what you want.
Check out: Things to watch out for in ColdFusion 9 with CF-ORM however keep in mind that some points are no longer true for 9.0.1
I've just started using Zend Framework and Doctrine as its ORM, and I have some doubts regarding the model. It's obvious that the purpose of the ORM is just to map my domain model to database model, but I'm curious how you would model various reports needed on a Web application?
From my point of view, and correct me if I'm wrong, I should avoid writing any queries in the controller (Doctrine Query Language queries, in this case). So, if I want some arbitrary report (e.g. revenue per department, split by month), should I have a special reporting "service" in the domain? This service would fetch my report from the database using ORM queries.
If you could shed some light on this topic, I'd be grateful.
For sure, sometimes DQL is insufficient. In Doctrine2 you can extend it. But Doctrine 1.x is not stupid and you can use native SQL with it: http://www.doctrine-project.org/projects/orm/1.2/docs/manual/native-sql/en
If ORM is insufficient, you can use native SQL. Reporting is the case where SQL queries become tooo complex for ANY simple QL you can image. So... I say go for native queries if you can't avoid it. But save Doctrine for everything else.