I would like to generate my models/entities into a custom folder/package and not to domain. Is this possible with the entity generator command?
it wasn't as easy for me. After refactoring the entity class, I had to change all the classes and .js files generated by jhipster. For example, #RequestMapping in the rest controller has to be changed by adding the new path to the entity (#RequestMapping("/myEntity") becomes #RequestMapping("newpackage/myEntity")).
No.
Of course, refactoring your domain classes is just a matter of dragging/dropping those files to another directory, if you have a decent IDE, so that shouldn't be an issue.
Related
I'm currently working on an ASP.NET project which I've not done before, and I need to use Entity Framework to access a database. I have a database already and following along with this tutorial: https://msdn.microsoft.com/en-gb/data/jj200620
I've managed to get Entity Framework to create the classes for the tables in my database but it has created them all in my Views/Home directory like so:
But from my understanding of MVC these should go in the Models directory? Is it safe to just cut and paste these generated files into Models or am I going to run into problems in the future because it's going to still be trying to use View/Home?
It should be safe to move them to Models. The models are compiled, not deployed as website content, so ASP.NET does not care about their exact location.
You will probably want to update the namespaces of the models, though. I'm guessing that the models were created with a namespace like YourNamespace.Views.Home, and you will want to change it to YourNamespace.Models.
Also make sure to update the namespaces to any references to your models (if you have any). You will get compile errors for any references that you missed EXCEPT for any references in cshtml files.
It would be a lot easier to just delete everything created by EF, and add your ADO.NET Entity Data Model (.edmx file) again into the right folder.
On step 3 of the EF guide in your question, when you add the ADO.NET Entity Data Model, make sure you add it into the Models folder. (Right click on the Models folder, then Add New Item...)
This code was generated for me after added entity framework code-first for SQL Server CE using NuGet. They did no changes to any other file. The file SQLCEEntityFramework.cs was created and placed in App_Start folder.
Does this mean it automatically gets executed or something? The same thing happened when I added Ninject for MVC 3. No code was added to the global.ascx file so I have no idea if its plug and play or I have to configure something.
[assembly: WebActivator.PreApplicationStartMethod(typeof(StackTorrents.WebUI.App_Start.SQLCEEntityFramework), "Start")]
According to:
http://haacked.com/archive/2010/05/16/three-hidden-extensibility-gems-in-asp-net-4.aspx
This new attribute allows you to have
code run way early in the ASP.NET
pipeline as an application starts up.
I mean way early, even before
Application_Start. This happens to
also be before code in your App_code
folder (assuming you have any code in
there) has been compiled. To use this
attribute, create a class library and
add this attribute as an assembly
level attribute. A common place to add
this would be in the AssemblyInfo.cs
class within the Properties folder.
To clarify, it gives you a way of hooking into several application start and application shutdown events WITHOUT having to change any existing code files (previously you had to edit Globals.asax.cs).
This is mostly a big deal when making packages as these events are really useful for bootstrapping Http modules and it is really difficult to write code into existing files.
Lets consider default ASP.NET MVC application folder structure, so it's looks like this:
-App_data
-Content
-Controllers
HomeController.cs
-Models
AccountModels.cs
-Scripts
-Views
My question is: Where is the best place to put Entity Framework Data Model (EDMX) file? Is it Models folder? Yes - we know that good solution is to introduce new Project and reference it to MVC application, but lets forget about this now.
For a small project, it should be part of the Model. For a larger product, the repository and the associated model could be in a separate assembly.
Well this is debatable, but i'd vote +1 for the Models folder.
The only other candidate would be App_Data, but this is generally for file-based databases (SQL Server CE .MDF, for example) and files you don't want served by IIS.
As the EDMX is an abstraction of the database, it should go into the Models folder.
If the project gets bigger, you should definetely move your EF Model into another project. To future-proof yourself from this, make your Controllers access the EDMX via Repository/Interfaces, so when you move the DAL over to another project, all you'll have to do is add the reference and add in the using statements.
I would put the EF-model (aka physical model) always in its own assembly or in a "core" assembly outside of main MVC application. The same applies for your business-logic / domain-logic / domain-services / etc. Separate the non-web stuff from the MVC-Web-Application.
This will help you re-use the core part of your app. For example when you need to expose it as a service, a command-line tool, migration-tool, etc.
Because storing this in its own assembly is so easy and takes you a few minutes I highly recommend doing this for each and every tiny app too.
My opinion is that you should create
a separate project for domain objects, datacontracts etc. etc...
Like MyProject.Infrastructure including many folders like
DataContracts, Model, Exceptions etc.
a separate project for DataAccess wich contains the DBContexts and the Repositories, this way you can easily manage migrations later on
is there any particular directory that i should put my code into in an asp.net mvc project
i have some extentions to the HtmlHelper class. Right now i have it sitting in the Content folder. is this correct? is there a better soluiton?
I usually create a separate project (or projects) for my own code, including my data layer, as class libraries. I then reference the libraries in my MVC web site.
you can put code wherever you want, but typically you want things organised. heres how i do it:
2 assemblies
MyProject.Domain
this contains all my domain code; business logic and entities
MyProject.Web
this contains controller code, views and assets like css/images
Your HtmlHelpers belong in the .Web project because they are mvc related (nothing to do with the domain). You probably want a new folder called Helpers or Extentions. Its really up to you, the key point is to decide where something belongs and to namespace it accordingly
I agree with what everyone else said, here's how one of my solutions would look like:
1- MyProject.WebUI
2- MyProject.DomainModel
3- MyProject.Test
4- MyProject.Extensions
This extensions project is new to me (actually since I knew about extension methods). It usually concludes sub-folders describing what the extension methods are used for, for your particular case, the folder name would be HtmlHelpers. I then reference this project (or its output library when using elsewhere). HTH
If you are going to re-use the same HTMLHelper extensions in different ASP.NET MVC projects, I'd suggest putting them in a class library which is completely seperate from your project.
I would like to add a field to an existing domain class. I do not want to lose my view files however as I know will happen if i run generate-all. Is there another way I can update the mapping etc?
I think this is a common concern.
This is not a direct solution to your problem, but this is what I do and works very well for me.
I never make direct modifications to the grails scaffolded artifacts (views and controllers)
I keep my production views/controllers separate from the scaffolded artifacts; through I use the scaffolded as the starting point of my application controllers and views.
If there are changes to the domain model, I re-generate the views and copy-paste (wherever possible) from scaffolded artifacts to hand-coded artifacts.
At some point, I either delete all the scaffolded artifacts from the app or just protect access to them.
Hope this helps.
There are a couple of ways to do this.
If you have not modified your generated views too much and are using version control, you could allow grails to overwrite your views and then merge the changes to the new templates with what is in version control.
If you have modified your generated views, you could just answer no to the prompt for overwriting the views. If you are only adding a new field, changing a field name or something simple like that, modifying the view templates should be pretty straight forward to do manually.
You would deal with any possible changes to the Controllers in the same way.
just declare it:
class MyDomain {
String newField;
}
Should be all you need to do.
Don't regenerate the views, just copy and paste another similar field to the one you are putting in the view(s) you want.