I have to configure model classes in every module and for every controller for table gateway.
Any way to use the same model folder and configuration for all modules?
Related
For one of my project which has .net Core 2.0 framework with MVC I want to implement Onion layer architecture to my project. My main issue is that I want to implement EF and Data model to particular class library.But whenever I tries to scaffold it creates under my Web Application. I want to know why it creates by default under Models folder and is that possible to provide path for data model under different class library, if yes how and if no why ?
I have resolved the issue:-
Step 1:- Open Class library and right click on dependency add these 2 package using nuget
A. Microsoft.EntityFrameworkCore
B. Microsoft.EntityFrameworkCore.SqlServer
Step 2:- Open Package Manager Console, Select Default Project as your class library, and then execute below command
Scaffold-DbContext "Data Source=.\SQLEXPRESS;Initial Catalog=Your Instance Name;User ID=sa;Password=test#123" Microsoft.EntityFrameworkCore.SqlServer -OutputDir Models
Okay, so I have an internal library for entities, and I have a web application which depends on the library.
So the dependency looks like this:
Web Application
Library
Entity Framework
The library is managed via an internal NuGet feed.
The problem I have is that every time I update the library within the web application, the install.ps1 script gets run for Entity Framework. This creates an EF folder (along with with Model1.tt, Model1.cs, Model1.Context.tt, Model1.Context.cs files) within the web application.
I don't want this obviously, so every time I update the library project, I have to delete files from the web application.
I feel there's something I'm missing here - how do I get to use Entity Framework as a dependency without it creating the EF folder every time I update the library project within the web application?
When we generate a maven AEM project, how do we decide the archetype to use? What are the deciding factors and best practices for the same?
You can find the a baseline structure provided in Adobe-Marketing-Cloud space on Github - aem-project-archetype
This is a very basic structure to start with and provides you following modules -
Core : Core bundle (java code goes here)
it.launcher - Baseline bundle to support Integration Tests with AEM
it.test - Integrations tests
ui.apps - Module for your components,template etc code.
ui.content - Project sample/test content or may be actual content (actual content in codebase is not a good practice)
Important thing to know prior to deciding the structure for your project is -
Is the implementation for multiple brands or to be used across multiple projects
Is there a need of platform which provides the basic/core functionality/features to be extended by different implementations
What is the roadmap for the project
That said, a best practice is to separate interface and implementation into different modules. Most modules will have 3 sub-modules (api, core and package).
api: OSGi specification describes a modular system with separate api
bundle
core: An implementation bundle providing a service
package: Packaging 2 bundles to generate AEM content package.
There can also be packages which consists of contents without api/service. Such modules do not follow convention of osgi bundles, for example configuration, components, design etc.
In most of the our AEM implementations, the project was generated from the com.cqblueprints.archetypes:multi-module Maven Archetype and its folder structure was refactored according to AEM 6 Implementation Guidelines.
All modules created are to organize dependencies in better way and have clean separation of package deployment.
Number of modules can vary depending on the project, some common reusable modules as baseline may include -
1. build-settings
This folder can hold commonly used settings and scripts :
- CI server scripts/setting
- Maven's settings.xml
- Reusable bash profile specific to project etc.
2. Common Module
This will have [api,core and content sub-modules]. As name suggests this should have generic service or utility classes that do not belong to any module or can be used across all modules. Be extra careful and justify reason for adding classes in this module else as a malpractice everything ends up on common module.
3. UI Module
This will have [api (optional if you need OSGI services here),core and content sub-modules].
- The core module holds all your SlingModel, WCMUse extensions and
supporting Pojos.
- Content package to contain all your UI functionality related to components, templates. Its important to structure this module correctly so that addition of components, pages etc doesn't make it unmanageable.
We created following structure in the content module, /apps/<your_project>/ui
components : all components goes here. Further sub categorized as [content,global,scripts]
install
page : page components
templates : page templates
4. Configurations Module
This module to carry OSGI, Cloud Configurations and if implemented the /conf based implementations as well. Conf based implementation sample here
OSGI Configurations Module : Package module with all configurations as content.
Cloud Configuration Module : Package module with all configurations as content
5. Sling Error Handler Module
Any error handling content should reside here. Sample configuration has author mode display error stack and in publish mode it returns 404 response.
6. Designs Module
Any error handling content should reside here. Sample configruation has author mode display error stack and in publish mode it returns 404 response.
7. Content Module
Packages sample content and/or test content. In some implementations we chose to keep test content as separate module.
8. Complete Module
The is the package module that gets compiled at the last and combines all the packages generated in above modules into a single package for deployment to the server.
If your application has lot of business logic or processing you could add up more modules, for instance in couple of projects we have following additional modules as well -
Grunt/Gulp build
Services/Operations (for business layer)
Validations
Data Import
Incontainer tests
Incontainer test content
In addition to these we created a pom project that abstracts all the dependencies, configurations, plugins, profiles specific to AEM project and used that as a parent for the project POM. This cleaned up the project pom and allowed for reusability across projects for same client.
Sample parent.pom here
Does MEF allow to host multiple Plugins in single DLL, so that i don't have to create a new class library for every new Plugin ?
Thanks.
You can have as many types in an assembly as you like, but whether or not those plugins would conflict is down to how you namespace and name them, and how they are exported.
I was wondering if it is possible to create a DNN module that references a compiled business layer, instead of using just the data provider approach that's included in the default project. How would such a project be deployed? Just copy the compiled assembly that I'm referencing into the website bin folder?
Yes, you can reference assemblies in the bin from your module's project.