for a highly modular application (implemented with OSGi) we use one module just for the domain model. The implementations of the interfaces are just simple POJOs for most flexibility (other modules which depend on the domain-module don't inherit any other dependency).
So you could see the environment like this: There are just these simple domain-objects being passed from one module to the other. So we could call them POJO-DTOs, right? The DTOs don't know anything of there data storage.
With this architecture a module has a minimal dependency to that domain-model. Modules can be easily developed independently.
One problem we are facing is that a module can implement its own internal domain using the same interfaces of the domain-module. So the two implementations need to be copied from one side to the other. This is an error-prone thing!
Has anyone a good technique/concept/library to copy/merge two implementations with the same interfaces?
Thanks!
Related
When working with ZIO layers you have to deal with a whole different concept of what dependency injection is.
Usual approach is not completely typesafe and depends on some form of runtime reflection, and a container that registers constructors and built instances (in case they're supposed to be singletons).
I, for instance, when working with Kotlin, tend to use Kodein (pretty awesome library), and Kodein uses the usual approach of building a container, binding constructors and well, the usual DI stuff
When working with ZIO layers there are no containers, there are no bindings, it's just plain old function composition on steroids.
I prefer that approach, but I'm missing a feature that only the traditional approach has: overriding bindings.
With that feature I can take my actual application container and surgically replace one of its bindings in order to do test different parts of the system, connected to the rest of the app.
More given the fact that with the usual approach there's no such thing as hidden dependencies (nor explicitly visible).
Anyway... Is there a way to achieve kind of a similar feature? If so, how?
Creating a module (bundle, package, whatever) with only interfaces seems to me a strange idea. Yet, I don't know the other best solution to solve the following architectural requirement.
There often appears a need for a set of utilities. In many projects I can see the creation of "utils" folder, or even a seperate package (module) with frequently used ones.
Now consider the idea that you don't want to depend upon a concrete utils set. Instead you, therefore, use interfaces.
So you may create the whole project, with multiple modules, dependent only on the "Utils-Interfaces" set, which could be a separate module. Then you think you can re-use it in other projects, as these utils are frequently used.
So what do you do? Create a seperate module (package, bundle...) with interfaces with definitions of the methods to be implemented by concrete utility-classes? And re-use this "glue-interfaces-packages" (possibly with other "glues", such as bridges, providers etc.) in your various other projects? Or is there a better way to design the archictecture regarding the utilities that could be easily switched from one to another?
It seems a bit odd to have an interface for utility methods as it should be clear what they do. Also in most language you won't have static dispatch anymore. And you wouldn't solve a problem by having interfaces for utility methods. I think it would make more sense to look for a library doing the same thing or writing your own if such functionality isn't already implemented. Very specific things should be tied to the project, though.
Let's look at an example in Java:
public static boolean isDigitOnly(String text) {
return "\\d+".matches(text);
}
Let's assume one would use an interface. That would mean that you have to have an instance of such an implementation, most likely a singleton. So what's the point of that? You would write the method head twice and you don't have any advantage; interfaces are used for loose coupling, however such generic utility methods aren't bound to your application.
So maybe you just want to use a library. And actually there is one for exactly this use case: Apache Commons. Of course you may not want to include such a big library for a single method. However, if you need this many utility methods you may want to use it.
Now I've explained how to use and reuse utility methods; however, a part of your question was about using different implementations.
I can't see many cases you wanted this. If, for example, you have a method specific to a certain implementation of sockets, you may instead want
A) the utility method as a part of the API
B) an interface for different socket implementations on which you have one common utility method
If you cannot apply this to your problem, it's probably not a utility method or I didn't consider it. If you could provide me with a more specific problem I'd be happy to give you a more concrete answer.
I know this question might seem to be answered before, but I feel that the answer varies from case to case, so after reading several posts, I'm not sure in my case which is the best for my architecture.
I have a Component Library that has a Data Model and basic functionality that should be available to any application implementing this component.
I have a boundary for this component which has an interface IReader to load and process files from the disk and IDataMapper to provide Database access and CRUD operations.
a few other interfaces for specific functionality like IObjectComparison to compare objects, IXMLSerialization fro XML serialization.
I'm not sure where to store the definition of these interfaces.
The options are:
1)- Within the core Library, then when I write the implementations I will have to include the implementation libraries within this core component with I'd like to maintain decopled from the implementations.
2)- In a separate library project (Assembly). All interfaces there and included to the core component and included by the implementation libraries.
3) - In the implementation Libraries, then the core component will have to include the implementation libraries.
The only case where it seems reasonable decoupled is if I put all interfaces in a separate assembly library where Core component includes and any implementations I might need.
What do you guys think are Pros/Cons of the best option?
All I want to achieve is a decoupled architecture.
So when I do
Constructor:
CoreComponent(IReader Reader, IDataMapper Mapper)
new CoreComponent(WindowsReader, SQLServerMapper)
and don't have to include WindowsReader or SQLServerMapper into the Core Component
Cheers.
I would go for option 1 - Core Library as it is accordance with how we do in DDD. In DDD we used to put IRepository interfaces in Domain Layer instead of DAL or any other such layer.
DIP says the higher level component would own the interface, as Wikipedia says...
where interfaces defining the behavior/services required by the high-level component are owned by, and exist within the high-level component's package.
This is most common practice but not a strict rule.
Option 2 is fine but you need to refer two DLLs in other projects but with option 1 only one reference is needed. Option 3 is not appropriate.
Hope it would help. Thanks.
Getting going now with NInject... :)
For a WinForms application, and in particular the business logic classes used within it, is there a rule of thumb in terms of which Classes once should hook up using IOC? For example if you have a Domain Model which is modelled by C# classes is the concept that all classes should be wired together using IOC?
IOC/DI allows you to design loosely coupled systems and manage your dependencies smartly and flexibly. This means that you can use these concepts anywhere including the presentation layer e.g. PRISM. That being said, you don't have to apply them to each and every class. For example, some classes provide basic building block type functionality such as string class in .NET that it is ok to take a dependency on the concrete implementation. Otherwise, you will end with an overly complex looking code that may go against keep it simple principle. Ask yourself if you want to test your classes and how hard it is to write a unit test. If the code and the dependencies are getting in the way of easily and quickly producing unit tests, then you might want to invert those dependencies to be in charge of controlling them.
In an n-tier architecture, the best place to put an object-relational mapping (OR/M) code is in the data access layer. For example, database queries and updates can be delegated to a tool like NHibernate.
Yet, I'd like to keep all references to NHibernate within the data access layer and abstract dependencies away from the layers below or above it. That way, I can swap or plug in another OR/M tool (e.g. Entity Framework) or some approach (e.g. plain vanilla stored procedure calls, mock objects) without causing compile-time errors or a major overhaul of the entire application. Testability is an added bonus.
Could someone please suggest a wrapper (i.e. an interface or base class) or approach that would keep OR/M loosely coupled and contained in 1 layer? Or point me to resources that would help?
Thanks.
It sounds like you are looking for the repository pattern. If you need more decoupling, you can inject the data dependencies with an Inversion of Control container.
Service Facade Pattern is one name. Simple contracts between business logic and data layer.
Service classes or beans (call it what you want) define and implement the contract, and orchestrate the lower data layer, often handling the transactional logic across data objects.
In Spring, you define an Interface, and then implement it. One implementation might be an OR/M, another might be raw JDBC or ADO.NET. In some frameworks, Aspect Oriented Programming allows you to inject declarative transactional logic without writing any code. It saves a lot of headache.
One caveat: When dealing with some OR/Ms like Hibernate, there is the use of proxy classes. This does pollute things, because there are a few instances where the proxy classes cause problems. In my opinion, that is an implemtation detail that should not escape the service layer. But with Hibernate, it does. Not sure about the .NET implementation.