I'm looking to develop a custom processor that leverages the functionality of s3-sink and then add some custom logic to it.
I could do it without using standard components. i.e. using S3 APIs to write files along with custom logic. I would like to know if there is any way I can leverage the functionality of standard component and extend it to add our custom logic.
If you want to invoke some logic before or after the S3Sink normal logic then you can use function composition and create a custom Sink application that imports the S3SinkConfiguration and defines a java.util.Function that is applied after the normal S3Sink logic.
You will need to set the spring.cloud.function.definition property to s3Consumer|myCustomLogicFunctionName.
However, if you want to tweak what the S3Sink logic actually is (not before or after it executes), you will have to look into what it offers for extensibility/configurability. The S3Sink app looks like this:
#SpringBootApplication
#Import({ org.springframework.cloud.fn.consumer.s3.AwsS3ConsumerConfiguration.class })
public class S3SinkKafkaApplication {
public static void main(String[] args) {
SpringApplication.run(S3SinkKafkaApplication.class, args);
}
}
As you can see its just a SpringBoot app that imports a single configuration class. All the logic/magic is in that configuration. It in turn leverages Spring Integration AWS S3MessageHandler.
What does the custom logic need to do? Maybe the underlying S3MessageHandler supports that via configuration/extension.
Related
I'm new to asp.net mvc world mostly a windows developer moving to web. Be nice...
I found ridiculous when I look at many examples of asp.net mvc web applications that the pass to their controllers a list of services
Like this
public CustomerController(ICustomerService customerService,
IAnotherService anotherService,
IYetAnotherService yetAnotherService,
IYetAgainAnotherService yetAgainAnotherService,
etc...
Would not be better to do something like
public CustomerController(IServices services)
{
}
public interface IServices
{
ICustomerService CustomerService{get;set;}
IAnotherServiceService AnotherService{get;set;}
IYetAnotherServiceService YetAnotherServiceService{get;set;}
}
Am I missing the obvious?
As anybody implemented the way I suggest in mvc4 or mvc5. I know mvc6 does it.
But I cannot use mvc6 at work.
Any samples using DI?
Thanks
What you're missing here is the fact that constructors with many parameters is a code smell often caused by that class having to many responsibilities: it violates the Single Responsibility Principle.
So instead of packaging the services to inject into a 'container' class that allows those services to be accessible using a public property, consider the following refactorings:
Divide the class into multiple smaller classes.
Extract logic that implements cross-cutting concerns (such as logging, audit trailing, validation, etc, etc)out of the class and apply those cross-cutting concerns using decorators, global filters (MVC) or message handlers (Web API). A great pattern for your business logic is the command/handler pattern.
Extract logic that uses multiple dependencies out of the class and hide that logic behind a new abstraction that does not expose the wrapped dependencies. This newly created abstraction is called an Aggregate Service.
I agree that for readability sake, even if you have multiple existing services which are also used in other applications, you could always wrap them in another class to avoid passing a long list of dependencies to the controllers.
When you have code in the API controllers that look like this:
public CustomerController(ICustomerService customerService,
IAnotherService anotherService,
IYetAnotherService yetAnotherService,
IYetAgainAnotherService yetAgainAnotherService,
...
That can be a code-smell and is an opportunity to refactor. But this does not mean the original code was a bad design. What I mean is in the API layer, we try not to clutter it with too many services that the controller is dependent on. Instead you can create a facade service. So in your example above, you refactor it to look like this:
public CustomerController(IServices services)
{
}
public interface IServices
{
ICustomerService CustomerService{get;set;}
IAnotherServiceService AnotherService{get;set;}
IYetAnotherServiceService YetAnotherServiceService{get;set;}
}
Which is good and then you can move the IServices to your service/business layer. The concrete implementation of that in the service/business layer will look like this:
public class AConcreteService:IServices {
public AConcreteService(ICustomerService cs, IAnotherServiceService as, IYetAnotherServiceService yas)
{
...
}
public List<Customer> GetCustomers(){
return _cs.GetCustomers();
}
public List<string> GetAnotherServiceData(){
return _as.AnotherServiceData();
}
public List<string> GetYetAnotherServiceData(){
return _yas.YetAnotherServiceData();
}
...
So that code will end up looking like your original code when implemented directly in the controller but is now in the service/business layer. This time it will be easy to unit test in the service class and the API layer will look much cleaner.
I just want to know what would be best practice/ widely used, I currently do my logging in the domain service layer, however anything that happens inside my web application layer is not logged.
I would like one centralized and simple location to do all my create/delete/update loggging...
I have heard of Elmah, not sure how useful it is for domain service layer logging only...
I currently do not use any framework for logging at all, I just string builder my log message or get the exception and flush it into the database... Is this the best way to go about it?
If it matters... I need to use Ninject to inject in my ILoggingService
NOTE: I am not talking about Logging User Activity... that will definetly reside only inside my domain service layer...
Haroon,
Leverage Ninject to create and manage the lifetime of an ILoggingService. The implementation of that service should be built directly on top of a well tested logging library like NLog or log4net.
Once you have an instance of the service, you can easily inject it into either you MVC controller or your domain layer. All logging should happen against that instance, not a static logging class.
This will allow you to have the unified logging you are looking for, with a clean separation of concerns.
imho logging should not be injected. The reason is that most of your services (if not all) will use logging.
If you look at most logging frameworks (like nlog), they are using a singleton/facade and abstract factories to provide logging.
Something like:
public static class LogFactory
{
private static ILogFactory _instance;
public void Assign(ILoggingFactory factory)
{
_instance = factory;
}
public ILogger CreateFor<T>()
{
return _instance.CreateFor<T>();
}
}
The design makes your services only dependent of one class and one interface. Thus it's still extremely easy to switch logging implementations.
In your class use the code like:
public class ServiceImp : IService
{
private ILogger _logger = LogFactory.CreateFor<IService>();
public void SomeMethod()
{
_logger.Warning("Something went wrong, but we can handle it. Hence only a warning");
}
}
In an MVC app, we the have need to create a configuration settings class that is needed throughout the app. It is a cross-cutting concern in that it is need in controllers, sometimes deep in the domain logic, as well as place like HtmlHelper extensions. The fact that it's needed is so many different places is what is tripping me up.
The class will wrap settings that are pulled from the web.config, as well as a table in a DB. The DB settings query will be cached so I'm not worried about that getting hit up for every request.
In years past I may have created some static type of class or singleton, but I don't want to lose the testability I have now. What would be the best way to instantiate this class and then to be able to access it through pretty much anywhere in the app?
I would continue to use a singleton. But a singleton which is wrapping an interface, which also makes it testable.
public class Configuration
{
private IConfiguration _config;
public static IConfiguration Instance { get { return _config; }}
public static void Assign(IConfiguration config)
{
_config = config;
}
}
Simply use Assign in global.asax or any of your unit tests.
If you want to do it the correct way, you should provide the configuration settings directly in the constructors of your objects.
Instead of
public class MyService
{
public MyService()
{
var confString = Configuration.Instance.GetConnectionString()
}
}
You would do:
public class MyService
{
public MyService(string confString)
{}
}
Finally, I would not have any configuration dependencies in HTML helpers. By doing so yuo are adding business logic to your views which breaks separation of concerns
I think the codeplex project mvccontrib provided some hooks to use
at least 3 IOC providers as far as I not windsor, structurmap, spring.net...
but I did not used it myself
you can find out more here
http://mvccontrib.codeplex.com/
and maybe you can look into the sourcecode of this project and see where you can go from there...
HTH
I would refactor my app not to use configuration everywhere. I use configuration in controllers only. My views do not have any logic, my domain model does just have business logic, not application logic.
How do I convert the following example to use one of the wicket/IOC integration packages?
I want to learn and understand the DI/IOC pattern. I have read a lot about it, but I've found it a little hard to grasp without digging into a code example. I have an example of a complete, working Wicket panel, which I think I want to convert to using DI.
The panel is basically a web UI editor for a list. It takes an IPanelFactory as a constructor argument. The constructor creates a list (DefaultRefreshingView), and the panel factory knows how to create a ViewPanel for each row. The panelFactory also knows how to create an add form, for introducing a new item into the list.
I will cut out a lot of code to get to the heart of what I think is relevant:
public interface IPanelFactory<T extends DomainEntity, U extends DomainEntity>
extends IDetachable {
IAddItemPanel<T, U> newAddItemPanel(String id);
Component newEditPanel(ViewPanel.ViewPanelParameters<T> parms);
Component newListPanel(String id, IModel<Collection<T>> listModel);
}
public class ListEditorPanel2<T extends DomainEntity, U extends DomainEntity>
extends Panel implements IHeaderContributor {
private static final long serialVersionUID = 1L;
private final IPanelFactory<T, U> panelFactory;
public ListEditorPanel2(String id, IModel<Collection<T>> listModel,
final IPanelFactory<T, U> panelFactory) {
super(id, listModel);
this.panelFactory = panelFactory;
final AjaxCell listCell = new AjaxCell("listCell");
DefaultRefreshingView<T> itemList = new DefaultRefreshingView<T>(
"itemList", listModel) {
#Override
protected void populateItem(final Item<T> item) {
Component editPanel = ListEditorPanel2.this.panelFactory
.newEditPanel(new ViewPanelParameters<T>("viewPanel",
item.getModel(), new EditPanelCallback(item)));
item.add(editPanel);
}
};
listCell.add(itemList);
add(listCell);
final IAddItemPanel<T, U> addItemPanel = panelFactory
.newAddItemPanel("addItemForm");
add((Component) addItemPanel);
Form<T> form = addItemPanel.getForm();
}
}
Each implementation of IPanelFactory provides different components for the View and Add sections. There can be multiple instances of ListEditorPanel2 that use different factory implementations in the same page hierarchy.
My thinking is that I want IPanelFactory to be an injected dependency. So...
Is this a good use case for DI/IOC, or does it not make sense to use it here?
How would I do this "by hand" without using an IOC container? (Am I doing it already?)
Which wicket-IOC integration should I use? I am using wicket 1.4.8 at present. I was going to try wicket-spring-annot, but it looks like that project is out of date.
How do I set up the IOC container to do this for my wicket components?
I dont quite understand your use case but i will try to answer your question anyway.
Wicket has great support for the 2 most popular DI containers namely Spring and Guice. Personally i prefer using guice since it i find it less bloated and easier to use. You need to understand how guice works and how guice modules are created. To intergrate you wicket application with guice, you do something like below on your wicket application init method:
Injector injector = Guice.createInjector(new AppModule(),PersistenceService.usingJpa().across(UnitOfWork.REQUEST).buildModule());
addComponentInstantiationListener(new GuiceComponentInjector(this, injector));
Here am instantiating a guice injector with 2 modules, namely appModule and Persistence module (ignore the persistenceModule details . am using warp persist for transactions)
In a guice module, you bind all the components that you would like to be injecting. I mostly bind my Daos and my services. I can then inject the same to my panels, pages and any other wicket component. I can also bind panels and other custom components so that i can inject them to other components as neccessary. I have however not found a situation where i will need to bind and inject a user interface component.
I am writing a desktop GIS application and it supports MapXtreme, MS Virtual Earth and our Custom Map Engine.Users of application can change the map engine at run-time by selecting from dropdownlist.I have a Factory class to change map engine like this.
public class MapFactory implements IMapFactory
{
public IMapEngine createInstance(MapType type)
{
if(type==MapType.MapXtreme)
return new MapXtremeEngine();
else if(type==MapType.VirtualEarth)
return new VirtualEarth();
//....other code
}
}
Can I use a Dependency Injection Framework to create suitable MapEngine implementation at run-time by type parameter?
Your example is the exact right pattern for conditionally instantiating an object. Anywhere you need to create an instance, accept IMapFactory in the constructor.
The most a DI framework should do is hand out the IMapFactory instance.