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.
Related
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!
I often use a framework that allow you to inherit from a certain class, and override a method there, and it will be invoked.
from the framework point of view, how is it done ? what pattern is this ?
Sounds like you are using a programming language / platform which provides metadata for the code. The metadata is used by the framework to find any classes which implement the certain class.
It's not a specific design pattern (not one that I know of in any way) but a technique which can be applied in most modern languages. For instance, ASP.NET uses this for it's global.asax file (and I use it in a .NET framework of mine).
It's typically used for application entry points to control the lifetime of the object.
Not sure in what context you are using the word framework, but what you describe sounds like polymorphism.
A little background: We're building a library/framework for working with scientific models. We have an interface Model which defines the operations that a model must implement, which is pretty minimal. That is: the Model interface defines the contract of a model from the point of view of a model implementor.
The framework adds a bunch of other functionality around the model, but right now client code has to access that functionality by using a bunch of other classes, such as ModelInfo, ModelHost, ModelInstance, etc.
In our application that uses this framework, we don't want to actually have to deal with all this mechanism of running models, etc. So we've decided to use the façade pattern to wrap up the framework functionality in an easy-to-use object. (We've already applied this pattern to other parts of the framework, with good success.)
Here is the question: given that we already have an interface Model, what would be a good name for the façade class? The Model interface is the contract between the framework and the model implementation, and the new class will define the contract between the framework and the client application.
Or, more generally: when we have an abstraction provided by a library or framework, how can we name the "two sides" of the abstraction so as to clearly identify the "provider" and "consumer" interfaces to the abstraction?
(If it matters, for this project we're using Java 6.)
I know this seems trite, but... have you considered using "ModelFacade" as the class name for the facade class? I think with documentation that indicates that the interface was already named Model, it seems relatively straightforward, and makes it very clear which design pattern you're using.
How about *Provider and *Consumer? I think you said it yourself in your question. Perhaps *Producer and *Consumer is a better match?
In discussions within our team, another option has been proposed: we can rename the existing Model interface to something else, and just call the new façade Model. In fact, they can both be called Model right now, because they will live in separate packages. (Although I'm not a fan of identically-named classes in different namespaces.)
Sounds like ModelInfo, ModelHost, and ModelInstance should all be members of Model.
See https://softwareengineering.stackexchange.com/questions/316840/is-it-bad-practice-to-name-a-class-with-a-facade-suffix for why you generally shouldn't name classes with the specific implementation used. Basically, some day you may want to use a different implementation of Model, which happens to not be a facade.
PureMVC uses a singleton named ApplicationFacade and registers all the models with methods like registerProxy which are defined in IFacade
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.
Within the OO paradigm, we choose to use classes because they help us to break the system down, and provide nice side benefits such as encapsulation, separation of responsibilities, inheritance, modularity, etc.
If we look at a software system at the component level, can we simply treat components in the same conceptual way, i.e. a component is simply a "Big Class"? Or is there more to it than that?
What extra considerations must be given when designing components?
EDIT:
I know that a class and a component are different things. I also understand that a component may contain many many classes, each of which have their own roles and responsibilities.
I'll see if I can explain myself better.
Classes allow us to solve bigger problems because they allow us to think and design more abstractly.
There are rules & techniques to determine how to break down and assign data and functionality to classes.
This seems like a very similar situation to that of component design, just at a higher level of abstraction. Do the techniques used to determine what classes are needed scale up to components, and/or are there other things that affect a high-level system design that don't apply at the class abstraction level?
what about using the project phase or role to differentiate them?
For example a component is a design-time unit (system architects, designers) whereas a class is an implementation-time unit (programmers). So designers speak about components (or subsystems or modules, the hight-level boxes in your architecture drawing) whereas programmer speak about components and classes (that implements components).
Under this view a component is implemented by one or more classes.
I often think of Component in the UML sense (see Wikipedia description), whereby it represents a "modular part of a system". In this sense it tends to represent a larger piece of functionality than a class and could in fact be composed from multiple classes.
Considerations I would give to designing components are:
How it could be re-used. In particular what are the use cases that warrant implementing something as a component rather than bespoke code (As a grad I used to make everything re-useable!)
Providing sensible interface(s), and in some cases additional simplified interfaces, perhaps using the Facade pattern.
Hope that helps.
In this (hypothethical) context a component can be thought of as a series of classes.
However depending on the technology you use, components can be more then a set of classes.
i.e. They may have additional properties and functionality which is not part of the classes which form them.
e.g. a COM+ component.
So it depends on a specific situation really.
According the UML v2 specification:
8.3.1 Component (from BasicComponents, PackagingComponents)
A component
represents a modular part of a system
that encapsulates its contents and
whose manifestation is replaceable
within its environment.
A component
defines its behavior in terms of
provided and required interfaces. As
such, a component serves as a type
whose conformance is defined by these
provided and required interfaces
(encompassing both their static as
well as dynamic semantics). One
component may therefore be substituted
by another only if the two are type
conformant. Larger pieces of a
system’s functionality may be
assembled by reusing components as
parts in an encompassing component or
assembly of components, and wiring
together their required and provided
interfaces.
When you use this definition, components appear to be all about Inversion Of Control.
Looking at the .NET framework for an example, the IComponent interface indeed provides IComponent.Site.GetService to achieve inversion of control through the service provider pattern. A more light-weight alternative is dependency injection.
Eh?
The "File Uploading" component may consist of lots of classes: Page to receive the file, class to save it, etc.
components are subsystems of classes.Classes provide the basic low level blueprint of an object interface while components adds some functionality to it.