I am looking for advise on how to develop a web application in Symfony2 by starting from a EER diagram. I appreciate a step-by-step primer of what you think is a reasonable way to develop.
Also, is there anything I should pay attention to avoid later failure?
Please suggest any tool I may use.
UPDATE: Let me clarify. Say I have the EER diagram below. A question is: is there a tool to convert it into symfony entity classes, with correct annotations about relationships (1:N, or N:M)?
To clarify even more.
Say I have developed a EER diagram as above.
By Workbench Export, I may get the sql queries to create the corresponding mySQL tables; hence I may use Doctrine/Symfony2's app/console doctrine:mapping:import to get a schema I may use to generate my Entity classes.
However all that is not exactly what I am looking for, since I would like to avoid that piece of reverse engineering. So, question is: is there a way to export a EER diagram to the Entity classes directly, and to leave mySQL table creation as really the last step?
If that is not really possible by Workbench/Doctrine/Symfony, is out there a different combination of tools which let me do so? (Zend; Ruby on Rails, ...)
UPDATE, it seems that Skipper Skipper does what I am looking for. Unfortunately it is not free/opensource (indeed a little pricey). Skipper has a export to ORM tool, which creates Entity classes for Doctrine (or other ORMs) from a EER diagram. I need to check how it performs with respect to relationships and annotations.
You can start from your EER diagram to define which doctrine entities your application is going to need and the relationship between them ( Note : If the relationships are not easy to spot you might need a class diagram ). Then I would suggest to follow an MVC design pattern for which Symfony is clearly oriented :
Once you have your entities you have your models.
Take a moment to define which routes your application is going to use
The easiest way to deal with controllers is to assign a different controller for each route (unless you really have a lot of routes)
Finally write your views to render your models and logic to the users.
Hope this helps.
Ocramius did in Doctrine ORM Module (for Zend Framework) a tool to visualize Entities diagram. It really helps to visualize the diagram to configure your objects relations...
I liked it in Zend, and used it a lot ! so I really missed it when I started to learn Symfony... I decided to find a way to do the same... and I did ! (it uses the yuml.me API)
I shared the bundle :
https://packagist.org/packages/onurb/doctrine-yuml-bundle
Installation is very easy in only 3 steps... Try it :)
I created a really nice script to do this. It converts the EER Diagram to Doctrine 2 entities which are symfony friendly and it allows you to totally customize how its done.
The first step is to download this tool (https://github.com/mysql-workbench-schema-exporter/doctrine2-exporter). I just installed it via composer (follow instructions on the github)
Next have the .mwb file be in the same directory as the script I am going to propose you make.
Next I created a script like this to customize the settings of that program.
autodoctrine.sh
php vendor/bin/mysql-workbench-schema-export youreerdiagram.mwb ./entities << EOF
`#Export to Doctrine Annotation Format` 1
`#Would you like to change the setup configuration before exporting` y
`#Log to console` y
`#Log file` doctrineconvert.log
`#Filename [%entity%.%extension%]`
`#Indentation [4]`
`#Use tabs [no]`
`#Eol delimeter (win, unix) [win]`
`#Backup existing file [yes]`
`#Add generator info as comment [yes]`
`#Skip plural name checking [no]`
`#Use logged storage [no]`
`#Sort tables and views [yes]`
`#Export only table categorized []`
`#Enhance many to many detection [yes]`
`#Skip many to many tables [yes]`
`#Bundle namespace []`
`#Entity namespace []`
`#Repository namespace []`
`#Use automatic repository [yes]`
`#Skip column with relation [no]`
`#Related var name format [%name%%related%]`
`#Nullable attribute (auto, always) [auto]`
`#Generated value strategy (auto, identity, sequence, table, none) [auto]`
`#Default cascade (persist, remove, detach, merge, all, refresh, ) [no]`
`#Use annotation prefix [ORM\]`
`#Skip getter and setter [no]`
`#Generate entity serialization [yes]`
`#Generate extendable entity [no]` y
`#Quote identifier strategy (auto, always, none) [auto]`
`#Extends class []`
`#Property typehint [no]`
EOF
This will create the doctrine entities for you. My particular settings turn on extendable entities because that way you can run this command over and over without overwriting model specific code. You just put your code in the class that is extending the base class. This will create a discriminator column in the database that you will want to ignore but its worth it for the logical separation.
Next you simply run the /vendor/bin/doctrine orm:schema-tool:create console command like in the symfony tutorials to have it create the database from the doctrine files! Let me know if this was clear enough.
References:
http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/tools.html
Related
I am currently looking into the repository patterns and read that repository patterns can be implement in 2 way:-
One repository per entity (non-generic) : This type of implementation
involves the use of one repository class for each entity. For example,
if you have two entities Order and Customer, each entity will have its
own repository.
and
Generic repository : A generic repository is the one that can be used
for all the entities, in other words it can be either used for Order
or Customer or any other entity.
Then I read about the Unit of Work concept and how it can relieve us from database inconsistencies that can be cause by the first way.
My confusion is regarding the second way.
Why would I be needing to use 'Unit of work' when I have created a generic repository?
Since there is no way for any inconsistency to occur.
One way to minimize redundant code is to use a generic repository, and
one way to ensure that all repositories use the same database context
(and thus coordinate all updates) is to use a unit of work class.
But since I am going to have a single generic repository then what is the need?
Usualy You don't have "single" generic repository.
In complex applications, sometimes you have to use many instances in a controller
(for example
var productsRepo = new Repository<Products>();
var userRepo = new Repository<Users>();
This are two different instances of generic repository, and they can cause inconsistent in db (or even Exceptions, if both have different dbContext and you try to modify entities in both repositories).
Thats why You have to manage dbContext properly, and Unit Of Work is one of many ways to accomplish it.
I have an existing sqlite db schema (about 30 table) which I have to import into my Android project.
I'd like to use greenDao in my code but I don't know how it's possible if I have already sqlite db created.
Is it possible to work with greenDao even if I haven't my pojo/entity class generated by greenDao Generator? Could I generate them manually?
I think I need also DaoMaster and DaoSession!??!
Thank you very much.
I've never done it, but theoretically, yes you can.
From greenDao FAQ page:
Can I use existing entity classes? Can I skip entity generation?
Yes. In your generator project, call setSkipGeneration(true) on entities you do not want to generate. Like this, you have the most possible control over your entities at the cost of manual maintenance. However, this is considered advanced usage and should be reserved for special cases only: the recommended way is to generate entities and use “keep sections” to inject custom code into them. If you choose to skip entity generation, you must either provide a constructor with all property fields in the order they were added in the generator project. Or alternatively, call setConstructors(false) on entities to make greenDAO use setters instead of the constructor to create entities.
I understand that you have to implement the generator project normally but skype de generation of the entities. This should generate the DaoMaster and DaoSession only.
I've been doing a few Symfony2 projects lately, using doctrine as the ORM.
One thing that's been bothering me a little bit is the mix in Entities between autogenerated code / boilerplate code (field definitions, getters, setters, mappings) and business logic.
You end up with ~600 lines of code entity files of which only maybe 10% is business logic (although of course a lot of the business logic will be in the Repository classes usually, but still).
I'm considering splitting up code to keep business logic in a separate class that would extend the Entity, for more clarity, like having an Entity folder with the boilerplate code and a BusinessEntity folder with the real code.
1) Do you consider this a good design pattern?
2) Could it be accomplished without too much trouble?
We have extended the EntityGenerator to generate traits instead of classes. Every entity is generated as a class and simply imports the trait which contains all the boilerplate code. This approach has several advantages.
You can still generate the entities and leave the custom business logic untouched
All the generated code is cleanly seperated from your custom code.
You can still extend from another entity in case you are using table inheritance or extending some base entity.
Trait are only supported from PHP >= 5.4.
Am I wrong saying that you could use entity repositories for your business logic?
http://www.masnun.com/2012/11/12/symfony2-doctrine-custom-entity-repositories.html
I'm attempting to setup Entity Framework using Code First on an existing database. The database isnt in great shape (poor naming convention and some constraints are needed). The application I'm building is an MVC app. I have a "Model", "Repository", and "Web" (mvc) tiers.
To setup EF and map my model objects (POCO objects), is it required that I match my objects to database tables? Can I, instead, use my own stored procedures for CRUD operations? Would it help if I use WCF data services?
I'm planning on using fluent configurations to map my objects, but having some issues due to the database schema. I'm know considering redesigning the database just to get EF to map correctly. Any suggestions would be greatly appreciated!!
Looks awfully similar to this question:
Does Entity Framework Code First support stored procedures?
The answers there may be helpful to you, as well as the discussion surrounding how Code First and Stored Procedures don't make a whole lot of sense.
Wow, Julie Lerman answered!
Yes, it's possible, but not particularly easy. In particular, you must call context.Database.SqlQuery<T>() where T is the entity type you want to return, and your SQL must match up to that entity type. Otherwise, you will have to massage a result set into a type.
In general, you will have to do most of this manually, although you could probably figure out a T4 template to generate it for you, or maybe use some other tool like CodeSmith.
I really like where symfony 2 is headed, I just really dont like doctrine, I love codeigniters active record db system, is there anyway I can completely remove doctrine from symfony and replace it with a DAL like of codeigniters ?
Doctrine 2 is a pure Data Mapper pattern implementation. Its advantage over Active Record is that you don't have to bend your model to a database schema or vice versa. In most cases your model and schema may evolve separately; you'll need to update the mapping metadata only.
Plus you don't have to extend/implement any special classes/interfaces. Your model consists of POPOs (Plain Old PHP Objects) and the mapping is managed by an external object — an entity manager. This allows for good OO design on the PHP side and good schema design on the database side.
So, I suggest you rethink your desire to go back to Active Record. It may take some time for the paradigm shift but it's worth it.
The thing that Doctrine is a default choice doesn't mean it's the only one. It's not tightly coupled to Symfony and can be replaced.
Symfony provides sensible defaults but gives you the freedom to change them.
For example, you might use Propel. It implements Active Record (as opposed to Doctrine2).
You can write your own ORM implementation if you'd like to.
Note that apart from ORM, Doctrine has some useful helper libraries. For example annotation reader is used in Symfony to parse annotations. If you use them you'll need this part of Doctrine.