In a Multitenancy B2C application, the interface created by the Application Startup Template applies well to the backoffice, but for the storefront website I think it would be necessary to create a blank UI project (angular or MVC).
What would be the best practice for keep the ABP infrastructure that provides functionality such as customization by Tenant, Tag Hellpers, Proxies, Localization, etc. without bringing unnecessary dependencies such as JS libraries and other components like menus, datatables, sidebars?
What you are looking for is a Public application template. Abp framework is created modularity in mind so that you can use modules in each other if they are developed in modular way.
I don't think it is feasable to say "add these projects and libraries".
However, you can check the microservice demo, PublicWebSite application at abp-samples to see which libraries are added so that you can modify an empty project as you desire.
Overriding a View Component The ABP Framework, pre-built themes and modules define some re-usable view components. These view components can be replaced just like a page described above.
https://docs.abp.io/en/abp/latest/UI/AspNetCore/Customization-User-Interface#overriding-a-view-component
Replacing ALL UI Theme Package with your custom Project by copy the Basic Theme (from Github).
MVC https://community.abp.io/articles/creating-a-new-ui-theme-by-copying-the-basic-theme-for-mvc-ui-yt9b18io
Blazor https://community.abp.io/articles/creating-a-new-ui-theme-by-copying-the-basic-theme-for-blazor-ui-qaf5ho1b
Or check these others links https://community.abp.io/articles/changing-ui-theme-for-abp-mvc-razor-pages-ui-ravx6a0o.
Related
I am starting to work on a new project so working on laying on the architechture at this moment.
So basically we want to keep a service oriented architecture using MVC web api.
So I had the following structure in mind:
Project.Core (All Poco classes)
Proect.Data (All entity framerwork)
Project.Service (All Web API ??)
Project.Web
We would be working for the first time on webapi here. So wanted to know how do we intergrate webapi here.
Most of the articles we saw read had created a mvc web application and had selected webapi in that. But we
were looking to create separate service layer just for webapi. Is this the correct practice to do that or
I am missing something here.
We basically wanted not to have a tight coupling b.w MVC web and web api here. If we create web api as part
of mvc then how can we separately access our web api.
WOuld appreciate inputs.
I normally use the project template provided by Visual Studio. Choose Empty ASP.NET project template and then select Add folders and references for Web API. It will create the folder structure needed/recommended purely for a Web API project without any MVC reference. I generally create a separate project for Data Access and use that from the Web API project.
I'm trying to learn dependency injection. The book/example I am following seems to be using an MVC project as just the UI layer within a broader architecture. The example includes a separate project for the domain layer and yet another project for the data access layer.
When I first learned MVC I came away thinking MVC was the entire architecture. V for view for UI layer, C for controller for domain layer, and M for model for data access layer.
So is using an MVC project as only the UI layer a proper and/or commonly accepted application of the MVC framework?
So is using an MVC project as only the UI layer a proper and/or commonly accepted application of the MVC framework?
Yes.
While it is possible to make an application entirely within the context of ASP.NET MVC, doing so means that the application will have to be written from scratch to use a different UI framework. Isolating the business logic into a separate set of services that are not coupled to ASP.NET MVC means that only the top layer would need to be replaced to move to a different UI framework, which also means that the application's lifecycle may extend beyond the end of ASP.NET MVC and/or it can be made into an application with a different UI framework (WebApi, WPF, etc) without too much trouble.
The purpose of dependency injection is to decouple your services from all other parts of the application, including each other. So by extension, it is only natural to build the business layer separately from the UI layer. Whether you physically have them in one assembly or multiple is really just a matter of preference.
Applying SRP to the MVC design pattern will lead you there. Same goes for MVVM. You are extracting logic from Model to other classes like Interactors, Services, Repositories etc.
From any point of view this is perfectly normal(and desirable). Your Model is just an abstraction of Several different layers.
I would suggest you to take a look at VIPER (not a car) - https://www.objc.io/issues/13-architecture/viper/ and you will see something that is occuring to you right now.
I've been checking quite a few examples related to Web Api, and they all create the model in the Models folder contained with the Web Api project but I'm curious as to how this should be handled if you want to use/re-use these models with various projects.
In the past, when using WCF REST, I would have created the following:
Business Model Project (PCL)
Business Layer Project
Data Layer Project
SQL Data Layer Project
WCF REST Project
Web App
Windows App
Third-Party Web app (javascript)
Mobile App (Xamarin)
Projects 2 to 9 would have all been referenced to Project 1 or objects would be created dynamically when using JavaScript. The business object project only contained POCO objects, most decorated with DataContract/DataMember attributes.
Can the same logic/Project breakdown be applied when using Web Api? Is it recommended or will I face problem at a later stage?
If it's not recommended, am I suppose to duplicate all my models? Doesn't seem to make sense so I thought I'd ask.
Thanks.
Short answer, YES. The same logic/Project breakdown can be applied when using Web Api. This is also how I implement my architecture. Your Web Api would just be another layer in your architecture. By doing it that way you will allow for greater re-usability of the models (DRY) and maintainability.
I am developing large web project, using IntellijIDEA (11.1.3).
I would like to have some environment, where I will be working under HTML templates. I won't use any server-side programming there, just HTML markup, CSS style sheets and JavaScript.
As well, I need different environment, where I will create dynamic application, using not only markup, style sheets and client-side programming, but also Maven, Spring MVC, Hibernate, PostgreSQL and, probably, other technologies.
I will use Tomcat to deploy both my template and my final application into container to view it in browser.
The question is how to structure my project?
That would be absolutely great if someone could show me step-by-step instructions of creating sample project, but any advises are appreciated.
IntelliJ IDEA 11 has a special Web module type for the plain HTML/JS projects, create one module of this type and another Java module for the rest of the technologies.
I have seen Sitemesh used with Spring and Freemarker(FTL). So I want to know what is Sitemesh and its use with FTL, with example.
#see: http://www.opensymphony.com/sitemesh/
What Is It?
SiteMesh is a web-page layout and decoration framework and web- application integration framework to aid in creating large sites consisting of many pages for which a consistent look/feel, navigation and layout scheme is required.
SiteMesh intercepts requests to any static or dynamically generated HTML page requested through the web-server, parses the page, obtains properties and data from the content and generates an appropriate final page with modifications to the original. This is based upon the well-known GangOfFour Decorator design pattern.
SiteMesh can also include entire HTML pages as a Panel within another page. This is similar to a Server-Side Include, except that the HTML document will be modified to create a visual window (using the document's Meta-data as an aid) within a page. Using this feature, Portal type web sites can be built very quickly and effectively. This is based upon the well-known GangOfFour Composite design pattern.
SiteMesh is built using Java 2 with Servlet, JSP and XML technologies. This makes it ideal for use with J2EE applications, however it can be integrated with server-side web architectures that are not Java based such as CGI (Perl/Python/C/C++/etc), PHP, ColdFusion, etc...
SiteMesh is very extensible and is designed in a way in which it is easy to extend for custom needs.
sitemesh is a web page layout framework.
OpenSymphony doesn't seem to be around anymore, so the best documentation for Sitemesh I've seen is available through their Wiki and as the Readme on their Github repository.
I would caution that if you're interested in using Sitemesh, or at least understanding its structure in a project, Sitemesh2 and Sitemesh3 have significant differences in their structure and implementation, though they work conceptually the same way.