I'm making an app that try to follow the Clean architecture guideline. The app use JavaFX as UI. JavaFX is make to use the MVC architecture. Is there a way to use both in conjunction like this?
My problem is i can't find a way to have a Controller and a Presenter that interact with the FXML file.
Currently i have this :
An FXML file that declare a controller with fx:controller attribute
A controller That handle event and called a usecase
A usecase like this:
public class SomeUseCase implements UseCase<Observable<String>> {
private SomeRepository repository;
public SomeUseCase(SomeRepository repository) {
repository = repository;
}
#Override
public void execute(Request request, Presenter presenter) {
SomeUseCaseRequest req = (SomeUseCaseRequest) request;
// I skip mapper that translate from request to entity and entity to repository
// And vice-versa for the respponse for clarity
presenter.render(this.repository.fetch(req.someParam));
}
}
Related
After reading some articles about the CDI and Java FX integration, and the source codes of javafx-weaver spring integration.
I decided to add CDI integration to Java FX via the existing javafx-weaver work to simplify the integration work.
The source code can be found here.
I added a simple producer to expose FxWeaver to the CDI context.
#ApplicationScoped
public class FxWeaverProducer {
private static final Logger LOGGER = Logger.getLogger(FxWeaverProducer.class.getName());
#Produces
FxWeaver fxWeaver(CDIControllerFactory callback) {
var fxWeaver = new FxWeaver((Callback<Class<?>, Object>) callback,
() -> LOGGER.log(Level.INFO, "calling FxWeaver shutdown hook")
);
return fxWeaver;
}
public void destroyFxWeaver(#Disposes FxWeaver fxWeaver) {
LOGGER.log(Level.INFO, "destroying FxWeaver bean...");
fxWeaver.shutdown();
}
}
The problem is when using fxWeaver.loadView to load view, the controller did not work as expected.
#ApplicationScoped
#FxmlView("HandlingReport.fxml")
public class HandlingReportController {
private final static Logger LOGGER = Logger.getLogger(HandlingReportController.class.getName());
#Inject
private HandlingReportService handlingReportService;
//fxml properties...
#FXML
private void onSubmit(){...}
}
As above codes, the dependent service handlingReportService in the controller class is null(not injected) when performing an action like onSubmit, it seems when JavaFX handles the #FXML properties binding it always used java reflection API.
If I change the method to public void onSubmit()( use public modifier), all FX fields become null when pressing the onSubmit button.
Any idea to fix this issue?
Marked the controller class as #Dependentscope to resolve the problem.
#Dependent
public class HandlingReportController { ...}
My theme has some sort of breadcrumb. The controller is always the category. To avoid repeat myself, I want to set it in the constructor of the controller for all actions like this:
class MyController:Controller{
public MyController() {
ViewBag.BreadcrumbCategory = "MyCategory";
}
}
When I access ViewBag.BreadcrumbCategory in the layout-view, its null. In a Action it works:
class MyController:Controller{
public IActionResult DoSomething() {
ViewBag.BreadcrumbCategory = "MyCategory";
}
}
I'm wondering that setting a ViewBag property is not possible in a constructor? It would be annoying and no good practice to have a function called on every action which do this work. In another question using the constructor was an accepted answear, but as I said this doesn't work, at least for ASP.NET Core.
There is an GitHub issue about it and it's stated that this is by design. The answer you linked is about ASP.NET MVC3, the old legacy ASP.NET stack.
ASP.NET Core is written from scratch and uses different concepts, designed for both portability (multiple platforms) as well as for performance and modern practices like built-in support for Dependency Injection.
The last one makes it impossible to set ViewBag in the constructor, because certain properties of the Constructor base class must be injected via Property Injection as you may have noticed that you don't have to pass these dependencies in your derived controllers.
This means, when the Controller's constructor is called, the properties for HttpContext, ControllerContext etc. are not set. They are only set after the constructor is called and there is a valid instance/reference to this object.
And as pointed in the GitHub issues, it won't be fixed because this is by design.
As you can see here, ViewBag has a dependency on ViewData and ViewData is populated after the controller is initialized. If you call ViewBag.Something = "something", then you it will create a new instance of the DynamicViewData class, which will be replaced by the one after the constructor gets initialized.
As #SLaks pointed out, you can use an action filter which you configure per controller.
The following example assumes that you always derive your controllers from Controller base class.
public class BreadCrumbAttribute : IActionFilter
{
private readonly string _name;
public BreadCrumbAttribute(string name)
{
_name = name;
}
public void OnActionExecuting(ActionExecutingContext context)
{
base.OnActionExecuting(context);
var controller = context.Controller as Controller;
if (controller != null)
{
controller.ViewBag.BreadcrumbCategory = _name;
}
}
}
Now you should be able to decorate your controller with it.
[BreadCrumb("MyCategory")]
class MyController:Controller
{
}
I have the same issue and solve it overriding the OnActionExecuted method of the controller:
public override void OnActionExecuted(ActionExecutedContext context)
{
base.OnActionExecuted(context);
ViewBag.Module = "Production";
}
Here is a better way to do this for .NET Core 3.x, use the ResultFilterAttribute:
Create your own custom filter attribute that inherits from ResultFilterAttribute as shown below:
public class PopulateViewBagAttribute : ResultFilterAttribute
{
public PopulateViewBagAttribute()
{
}
public override void OnResultExecuting(ResultExecutingContext context)
{
// context.HttpContext.Response.Headers.Add(_name, new string[] { _value });
(context.Controller as MyController).SetViewBagItems();
base.OnResultExecuting(context);
}
}
You'll need to implement the method SetViewBagItems to populate your ViewBag
public void SetViewBagItems()
{
ViewBag.Orders = Orders;
}
Then Decorate your Controller class with the new attribute:
[PopulateViewBag]
public class ShippingManifestController : Controller
That's all there is to it! If you are populating ViewBags all over the place from your constructor, then you may consider creating a controller base class with the abstract method SetViewBagItems. Then you only need one ResultFilterAttribute class to do all the work.
I'm trying to inject business logic implementations into web API base controller. Somehow property in base controller is always null.
Also how can I do lazy injection?
Startups.cs
public IServiceProvider ConfigureServices(IServiceCollection services)
{
// Add framework services.
services.AddMvc();
var containerBuilder = new ContainerBuilder();
containerBuilder.RegisterType<ViewBusinessLogic>().As<IViewBusinessLogic>().
PropertiesAutowired();
containerBuilder.Populate(services);
var container = containerBuilder.Build();
return container.Resolve<IServiceProvider>();
}
Interface, implementation and base controller:
public interface IViewBusinessLogic
{
IEnumerable<dynamic> GetView(Guid viewId);
}
public class ViewBusinessLogic : BusinessLogic, IViewBusinessLogic
{
public IEnumerable<dynamic> GetView(Guid viewId)
{
return new List<dynamic>
{
new { Test = "Test1" },
new { Test = "Test2" }
};
}
}
public abstract class BaseController : Controller
{
public IViewBusinessLogic ViewBusinessLogic { get; }
}
Controllers aren't resolved by the DI framework by default. You need to add AddControllerAsServices to have them be resolved by the DI of your choice.
From this GitHub issue:
Hi,
Maybe I'm wrong but as I tested deeply (and checked Mvc source code), Controllers are not resolved from IServiceProvider, but only constructor arguments of them are resolved from IServiceProvider.
Is that by design? I'm very suprised. Because, I'm using a different DI framework which supports property injection. And I can not use property injection since Controller instances are not requested from IServiceProvider.
Have you added AddControllersAsServices in your Startup (https://github.com/aspnet/Mvc/blob/ab76f743f4ee537939b69bdb9f79bfca35398545/test/WebSites/ControllersFromServicesWebSite/Startup.cs#L37)
The example above quoted for future reference.
public void ConfigureServices(IServiceCollection services)
{
var builder = services
.AddMvc()
.ConfigureApplicationPartManager(manager => manager.ApplicationParts.Clear())
.AddApplicationPart(typeof(TimeScheduleController).GetTypeInfo().Assembly)
.ConfigureApplicationPartManager(manager =>
{
manager.ApplicationParts.Add(new TypesPart(
typeof(AnotherController),
typeof(ComponentFromServicesViewComponent),
typeof(InServicesTagHelper)));
manager.FeatureProviders.Add(new AssemblyMetadataReferenceFeatureProvider());
})
// This here is important
.AddControllersAsServices()
.AddViewComponentsAsServices()
.AddTagHelpersAsServices();
services.AddTransient<QueryValueService>();
services.AddTransient<ValueService>();
services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
}
As for the second part of your question: I don't think it's possible to have lazy instantiation via IoC container at all. Best fit for you is to create a factory class and inject the factory rather than the concrete service.
But usually you don't need lazy instantiation anyways, the instantiation of services should be fast. If it's not, you probably doing some funky stuff in the constructor (connecting somewhere, or doing other long running operations), which is an anti-pattern.
I have a question for the article, which probably many of us have read: Dependency Injection in ASP.NET Web API 2.
Let's assume, that the ProductRepository at some later point in time needs to delegate to some other service. How should ProductRepository request the concrete instance from the dependency injector at that later time as it is a bad practice to inject the dependency injector itself into the ProductRepository?
You can inject the new service inside the ProductRepository just like you injected the IProductRepository into ProductsController.
public class ProductRepository : IDisposable
{
private readonly IOtherService m_OtherService;
public ProductRepository(IOtherService other_service)
{
m_OtherService = other_service;
}
...
}
If you register IOtherService successfully in the container, the container would be able to create ProductRepository and ProductsController successfully.
If it is a problem for you to have the OtherService created everytime (maybe you will not use it all the time), you can use the factory pattern. For example:
public interface IOtherServiceFactory
{
IOtherService Create();
}
public class ProductRepository : IDisposable
{
private readonly IOtherServiceFactory m_OtherServiceFactory;
public ProductRepository(IOtherServiceFactory other_service_factory)
{
m_OtherServiceFactory = other_service_factory;
}
...
}
Now, you can create an instance of OtherService only when you need it.
You have to create an implementation of IOtherServiceFactory and register it with the container.
I am not grasping something when creating my repository pattern with EF Code First. If I want to abstract out EF I would have to make my repository be of type IObjectContextAdapter, no? That is what DbContext implements. If I later switch to use something like NHibernate or some other 3rd party ORM, it may not implement IObjectContextAdapter.
Is my only solution to create a wrapper that wraps the ORM and does return an implementation of IObjectContextAdapter? If so, what is the point?
I'm not sure you have to implement IObjectContextAdapter when creating a repository pattern with EF. The main difference between using EF or something like NHibernate will be how to wrap either the DbContext or the ISession respectively.
Here is a sketch of how an EF code-first repository could be written:
public interface IRepository<TEntity>
{
void Save();
}
public class Repository<TEntity> : IRepository<TEntity>
{
private readonly IDbSet<TEntity> entitySet;
public Repository(DbContext context)
{
this.entitySet = context.Set<TEntity>();
}
public void Save()
{
return this.entitySet.SaveChanges();
}
}
This allows the actual DbContext to be injected.