I've successfully created a basic Spring Web MVC application using Roo, which I might add, was a treat! The application uses persistence (HIBERNATE + HYPERSONIC_IN_MEMORY), which is what you'd want for many POJOs.
Now, suppose I'd like to write some custom method which is to be accessed from the View-side, like end-of-day calculations or what have you. My immediate thoughts about how to implement these are either
1) Create an entity, keep it from using persistence and implement the desired method(s) for this class, rely upon MVC-scaffolding for presentation
or
2) Create the POJO + View + Controller manually
What is my best alternative? Is 1) even possible (i.e. not using persistence for entities through roo)? And if so: is it so that the .java files may be freely edited, while the .aj files are handled by Roo?
Thanks in advance!
Option 1 is absolutely Ok using Roo's entity command. You can create new entity in Roo shell and then perform scaffolding without any problem. And then you can edit your *.java part without problems too. The only recommendation is to keep Roo shell running while editing.
Related
There is a project in Symfony, who want to remake using MVC. The project has controllers and twig patterns , it is only necessary to fasten model.In which Symfony project directory to properly create model files ? Is there anything in Symfony tool allows to do it , rather than just to create these files and to connect them to the controller ?
Use Symfony standard edition as your starting point. If you try to make something own without prior experience with code organization in Symfony you will make it only worse.
https://github.com/symfony/symfony-standard
Standard edition above 2.8 version is pretty slim and doesn't force you to use everything if you don't need to.
If you need only "Model" classes then create them in src/AppBundle/Model and if you need Entities that will be persisted in database put them in src/AppBundle/Entity. Read about generation here http://symfony.com/doc/current/doctrine.html I will help you started
Is there a way in symfony2 that you can pre-define a procedure for inserting the basic data to the database for the application to work?, this is for not sharing an SQL script.
I see this as a doctrine procedure that is executed when you decide to update the schema. So it will check if there is the basic configuration data, if not, it will insert it. Is there something like that?
Thanks in advance
From the Symfony2 website
You have to use DoctrineFixturesBundle
There isn't such a feature embedded in SF2 and / or Doctrine2.
But you can create your own command to add this behavior to your application / bundle :)
As Picoss said, there is the Doctrine Fixtures Bundle but it isn't part of the Symfony2 core.
I need to be able to perform all of the available functions that the Package Manager Console performs for code first DB migrations. Does anyone know how I could accomplish these commands strictly through user defined code? I am trying to automate this whole migration process and my team has hit the dreaded issue of getting the migrations out of sync due to the number of developers on this project. I want to write a project that the developer can interact with that will create and if need be rescaffold their migrations for them automatically.
PM is invoking through PowerShell and PS cmdlets (like for active directory etc.)
http://docs.nuget.org/docs/reference/package-manager-console-powershell-reference
The Package Manager Console is a PowerShell console within Visual
Studio
...there is essentially very little info about this - I've tried that before on couple occasions and it gets down to doing some 'dirty work' if you really need it (not really sure, it might not be that difficult - providing you have some PS experience)
Here are similar questions / answers - working out the PS comdlets is pretty involving - in this case it has some additional steps involved. And PS tends to get very version dependent - so you need to check this for the specific EF/CF you're using.
Run entityframework cmdlets from my code
Possible to add migration using EF DbMigrator
And you may want to look at the source code for EF that does Add-Migration
(correction: this is the link to official repository - thanks to #Brice for that)
http://entityframework.codeplex.com/SourceControl/changeset/view/f986cb32d0a3#src/EntityFramework.PowerShell/Migrations/AddMigrationCommand.cs
http://entityframework.codeplex.com/SourceControl/BrowseLatest
(PM errors also suggest the origins of the code doing the Add-Migrations to be the 'System.Data.Entity.Migrations.Design.ToolingFacade')
If you need 'just' an Update - you could try using the DbMigrator.Update (this guy gave it a try http://joshmouch.wordpress.com/2012/04/22/entity-framework-code-first-migrations-executing-migrations-using-code-not-powershell-commands/) - but I'm not sure how relevant is that to you, I doubt it.
The scaffolding is the real problem (Add-Migration) which to my knowledge isn't accessible from C# directly via EF/CF framework.
Note: - based on the code in (http://entityframework.codeplex.com/SourceControl/changeset/view/f986cb32d0a3#src/EntityFramework.PowerShell/Migrations/AddMigrationCommand.cs) - and as the EF guru mentioned himself - that part of the code is calling into the System.Data.Entity.Migrations.Design library - which does most of the stuff. If it's possible to reference that one and actually repeat what AddMigrationCommand is doing - then there might not be a need for PowerShell at all. But I'm suspecting it's not that straight-forward, with possible 'internal' calls invisible to outside callers etc.
At least as of this post, you can directly access the System.Data.Entity.Migrations.Design.MigrationScaffolder class and directly call the Scaffold() methods on it, which will return you an object that contains the contents of the "regular" .cs file, the "Designer.cs" file and the .resx file.
What you do with those files is up to you!
Personally, I'm attempting to turn this into a tool that will be able to create EF6 migrations on a new ASPNET5/DNX project, which is not supported by the powershell commands.
I'm starting with a Symfony2 project. I know the framework basics but I have a question:
Where is the right place to pot those helper classes I create for help or for the business logic?
Max's answer is correct. However I question the path he recommends for your code.
The following classes and files have specific emplacements:
Service Container Extensions (belong in) DependencyInjection/
from http://symfony.com/doc/current/cookbook/bundles/best_practices.html
That says your Services should be placed in a folder called 'DependencyInjection', not 'Services'. In full, it should be src/Foo/BarBundle/DependencyInjection
I say this as someone that had the former and has just finished moving them all to the latter (!)
What #Adam says is wrong, you have to store your Dependency Injection Extensions in DependecyInjection directory, not the services itself. In the documentation says that you can store your (custom) business logic classes in any place you like.
http://symfony.com/doc/current/best_practices/business-logic.html
The best way to keep the business logic is create service to handle all the logic. So it will be in:
src/Foo/BarBundle/Service
and you need to call the service in the services.yml.
I recently did some small work on an existing Symfony2 project. As described by answer from Tuong Le, I created my Helper classes under the Helper directory of the bundle and class name with Helper suffix i.e. the helper class is located at:
src/MyBundle/Helper/MyUtilHelper.php
I can use MyUtilHelper class in my bundle without calling the service container i.e. I didn't need to call.
$container->get('my_util');
I don't really know whether there is some special config. in my setup; someone already got it setup and I was just adding new functionality.
You can create the custom classes under your Bundle, such as under a folder Helper/..
However, to use those helper in your code, you'll need to define those Helper(s) in your service description file (such as services.xml)... Then you can use $container->get('your_helper')->
According to official documentation - in particular - Symfony Best Practices - you should store your services in Utils folder under the src. I belive, that this is correct way regardless of whether you want or don't wont to make the functionality provided by services of your bundle available to other parts of application via Service Container. Furthermore, you can store helper classes in any place you consider suitable. Concerning #Adam Knowles and #PachinSV answers - they are not quite right because they do not answer your question - "Where is the right place to pot those helper classes I create for help or for the business logic?" or "Where to store classes which I want to register and use via Service Container" - but not where to put bundle Extension class - which main purpose is to provide information about configuration which should be automatically loaded from your bundle to apps Service Container during the process of booting the Kernel.
Is there a way to check that a DbContext matches the database when the database was not created by EF code first?
I am looking for similar functionality to Database.CompatibleWithModel but there is not metadata.
There is currently no way in EF to do this; however, you may be able to use the DDL script as a starting point for verifying that all the artifacts exist in the database. To get this script, use
string ddlScript = ((IObjectContextAdapter)myContext).ObjectContext.CreateDatabaseScript();
Some tools may be able to use this script to do a schema compare against your database. This will tell you if your model is compatible.
Have you tried using Entity Framework Power Tools.
you can use the tools to Reverse Engineer Code First - Generates POCO
classes, derived DbContext and Code First mapping for an existing
database.
And then maybe you can compare the reversed engineered information with what you already have.