At this moment I have a dynamic abstract factory with a singleton implementation of the class Factory where I store all the factories. Every factory has it's own types which there can be created instances out.
Those factories also got the RegisterType methode which I have created in order to register types from outside this project (DLL).
I want to register a type from outside the project. But in order to do that, ProjectA and projectB has to know information about each other.
So my question is, how can projectA and projectB know about each other without getting this error "Circular Dependency on References".
This blog post from Steve Smith directly addresses your question I believe.
Re-reading your question, the link I posted is not relevant, as you are dealing with 2 projects.
With most projects (web, desktop, even most apis) you typically have a project that is your entry point, your other project should contain dependent code or infrastructure code, there should be no bi-directional couple of the 2 (or more) projects.
It might be appropriate to use an IoC framework and register your dependencies, you would do this in lets say ProjectA, and provide to your factories types from ProjectB.
Be sure to abstract by using interfaces when passing these factories (and other types) into ProjectB where the implementation resides from ProjectA, then these interfaces can sit in ProjectB and not need any backward dependency.
Related
I'm a PHP programmer that has applied for an ASP.NET job. They gave me an assignament to make an application (of my choice) that implements a multi-tier arhitecuture.
I have alot of dillemas. As I understand, multi-tier is a concept that doesn't have a universal form and everyone should decide what is best for them. However, they advised me that the presentation layer should not have any refferences to the data access layer, which makes sense. But...
I created a new project with Add new project (that has controllers and views) who is a presentation layer. Now, in the presentation layer, there is also a class library that uses Ninject to inject dependencies for the entire application called NinjectIoC. NinjectIoC has to have a refference to the presentation layer project in order to inject dependencies directly in the controller as an argument. It also has to have refferences to all the other layers (DataAcessLayer, BusinessLayer etc...) order to bind them to their dependencies.
The main problem is that presentation layer project has to also have a refference to the NinjectIoC to create the StandardKernel inside Global.asax which creates a cirucullar dependency and is not permitted.
The only solution is to add a refference to the presentation layer project of all the layers (including DataAccessLayer) which, as I understand, is a bad thing. But, that is the only way to bind all the interfaces of all the layers and execute it inside Global.asax.
Am I thinking wrong?
EDIT:
NinjectIoC has Ninject installed and has a refernce to all the layers in order to bind them across the application. It has to have a reference to the UI in order to be called in Global.asax
UI has to have a reference to NinjectIoC so it can call it in Global.asax for controller binding.
I tried to create an intermediary class library that has a reference to NinjectIoC. That library is referenced in the UI. The problem is that that also creates a circular dependency beacuse NinjectIoC has to have a reference of the UI in order to bind the controllers.
Multi-tier can simply mean that there is a DAL, a BL, and a UI Layer. And the requirement to "not reference the DAL in the UI Layer" can simply mean that your UI layer (MVC4 app) can only reference the BL. This is simple to achieve, for example like this:
An UI Project (MVC4)
An Entities project (Class Library): define here the entities used, and reference it from all the necessary layers (this helps avoiding circular references)
A BL project (Class Library): this must reference the Entities, and the DAL project
A DAL project (Class Library): this references the Entities project
This is the classical, most simple, multi-layered project.
In the final compilation, of course, the indirect dependencies will include the UI project and the 3 libraries, but you don't need to add a reference to the DAL in the UI.
Another different question is using the IoC pattern. In this case, to solve the circular references problem, I recommend you to define separately projects of "Interfaces" and projects of "Implementations" for each layer. Something similar to the previous structurem, but with this changes:
An UI Project
An Entities project
A BL Interfaces project
A project that implements the BL interfaces
A DAL Interfaces project
A project that implements the DAL Interfaces
You need to define which is the main project. It's usually the UI project. This project is the one that will have all the dependencies.
In this case, the UI project depends directly on the BL Interfaces project. And the BL Interfaces will depend on the DAL Interfaces. In a few words, your UI project will only have direct dependencies with the BL Interfaces.
The question is that, when you try to run the code, it will need to solve this dependencies, i.e. find the implementation of the interfaces, and there dependencies. This is the "compositio root" of your application, and it's where you need to register the dependencies. I.e, this is the place where you need to define which concrete implementation will be use for each interface. And, if this implementation depends on other interfaces, you have also to define their implementations. Depending on the framework (I don't know if you can do it with NInject) you can do this dynamically, without the need to add references to the implementation projects. However, even if you have to include references to all the other implementation and interfaces projects you'll have not circular dependencies, and your UI will have not dependencies on the DAL or implementation layers. You only need them for registering them in the IoC Container, which is a very different question. (If you use constructor injection, you get the maximum possible decopuling using this project structure).
Keeping one or several separated entities projects allows you to avoid circular references, and direct dependencies between project. For example, if you defined the entities in your DAL project, nad you use them in your UI project you'd need to add a reference to the DAL project. This problem dissapears if the entities are declared in a separate project.
The pure IoC, like the "Onion Architecture" goes far beyond this by defining the entities and necessary interfaces of dependencies in the main project (UI project), then implementing these dependencies in other projects, and solve them dynamically, to avoid circular references. I.e. all the other projects depend directly or indirectly on the UI project, and not the other way round. In this case you need to solve the dependencies dynamically to avoid the circular references.
As you can see there are many options, and I've shown you several examples of working solutions.
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.
Can someone explain how the organisation of classes in Pharo works in different versions of Pharo?
All Classes are part of the Smalltalk global (have always been, seem to stay like this?)
Classes can have a Category, but thats only a kind of tag? (has always been, seems to stay like this? But the categories are somehow mapped to packages sometimes?)
There are different kinds of Packages in different Versions of Pharo
MCPackages representing Monticello Packages
PackageInfo
RPackage (Pharo 1.4)?
In addition there is SystemNavigation which somehow helps navigating classes and methods based on some of the above mentioned constructs?
Classes
The fact that classes are keys in the Smalltalk global is an implementation detail. As long as there is a single global namespace for class names, it is likely that the implementation will stay the same.
Class Categories
The class category is very much like a tag. A class can only be in one category at a time. Originally the class category was used by the Browser for organizing the classes in the system.
When Monticello was created, the class category was overloaded to also indicate membership in a Monticello package theMCPackage and PackageInfo classes were created to manage this mapping.
PackageInfo does all the heavy lifting: finding the classes and loose methods that belong to a package.
MCPackage is a Monticello-specific wrapper for PackageInfo that adds some protocol that wasn't necessarily appropriate for the more general PackageInfo.
Packages
Overloading the class category for package membership was a neat trick to ease the adoption of Monticello (existing development tools didn't need to be taught Monticello), however, it is still a trick. Not to mention the fact that the implementation of PackageInfo was not very efficient.
RPackage was created to address the performance problems of PackageInfo and to be used as part of the next generation of development tools.
Both package implementations will continue to exist until PackageInfo can be phased out.
SystemNavigation
As Frank says,
SystemNavigation is a class that, as its name suggests, permits easy
querying of a number of different things: the classes in the image,
senders-of, implementors-of, information about packages loaded in the
image and so on.
Classes are, at the moment at least, the keys in the Smalltalk dictionary.
PackageInfo contains information about a grouping of classes and extensions to other packages.
A Monticello package contains a deployable unit of code. Usually one of these will correspond to a PackageInfo instance. (Hitting the "+Package" button in a Monticello Browser will create one of these, for instance.) A Monticello package may contain pre-load and post-load scripts, so the two classes perform separate, if related, functions.
SystemNavigation is a class that, as its name suggests, permits easy querying of a number of different things: the classes in the image, senders-of, implementors-of, information about packages loaded in the image and so on.
Many articles/books/.... talk about class or package dependency, few explain what it is. I did find some definitions, but they vary and probably don't cover all cases. E.g.:
"when one class uses another concrete class within its implementation" (so there exists no dependency on an interface?)
"when a class uses another as a variable" (what about inheritance?)
"if changes to the definition of one element may cause changes to the other" (so dependency is a transitive relationship not just on packages, but also on class level?)
"the degree to which each program module relies on each one of the other modules" (but how do you define "relies"?)
Further aspects to consider are method parameters, dependency injection, aspect oriented programming, generics. Any more aspects?
So, can you give a (formal) definition for dependency amongst classes and amongst packages that is fool-proof and covers all these cases and aspects?
If you are asking for dependency in the context of inversion of control or dependency injection, well, you're probably interested in classes that interact with one another directly. That means mostly constructor parameters and properties.
In the context of a UML domain diagram, you're probably interested in "real world" dependency. A dog needs food. That's a dependency. The dog's Bark() method returns a Sound object: that's not something you're interested in, in a UML domain model. The dog doesn't depend on sounds to exist.
You could go philosophical on this also: All classes depend on each other to accomplish a common goal; a (hopefully) great software.
So, all in all, dependency or coupling is not a matter of yes or no. It really depends on the context and on a degree of coupling (weak, strong). I thinks that explains why there are some many divergent definition of dependency.
I wrote a blog post on that topic a while ago: Understanding Code: Static vs Dynamic Dependencies. Basically you need to make a difference between static dependencies, those that are resolved by the compiler at compile-time, and dynamic dependencies, those that are resolved by the runtime (JVM or CLR) at run-time.
static dependencies are typically provoked by calls to static/final methods, read/write to a field, in the definition of the class C the implementation of the interface I by C ... all these associations between code elements that can be found explicitly in the bytecode and source code.
dynamic dependencies are typically provoked by everything that abstracts a method call at compile time, like calls to abstract/virtual methods (polymorphism), variables or parameters typed with an interface (the implementation class is abstracted at compile-time), but also delegates (.NET) or pointers to function (C++).
Most of the time, when you'll read about dependencies in the literature, they are talking about static dependencies.
A static dependencies is direct (meaning not transitive). A tool like NDepend that I mention in the blog post, can also infer indirect (or call it transitive) static dependencies from the set of direct static dependencies.
The idea I defend in the blog post is that when it comes to understand and maintain a program, one needs to focus mostly on the static dependencies, the ones found in the source code.. Indeed, abstractions facilities are used to, well ... abstract, implementation for callers. This makes source code much more easy to develop and maintain. There are however situations, typically at debugging time, where one needs to know what's really behind an abstraction at run-time.
This post is about static dependency - for dynamic dependency and the difference, see
Patrick Smacchia's answer.
In an easy to understand way: an entity (class or package) A depends on an entity B when A cannot be used standalone without B.
Inheritance, aggregation, composition, all of them introduces dependency between related entities.
so there exists no dependency on an interface?
there is, but interface only serves as the glue.
what about inheritance?
see above.
so dependency is a transitive relationship not just on packages, but also on class level?
yep.
but how do you define "relies"?
see above "easy to understand" definition. also related to the 3rd definition you posted.
Update:
So if you have interface A in Package P1, and class C in Package P2 uses A as
method parameter, or
local variable woven into C via AOP, or
class C implements A, or
class C<E extends A>,
then C depends on A and P2 depends on P1.
But if interface A is implemented by class B and class C programs against the interface A and only uses B via dependency injection, then C still (statically!) only depends on A, not on B, because the point of dependency injection is that it doesn't make glued components dependent.
I try to set-up a clean and flexbible application-framework for data-centric applications with silverlight-only UI. I want to have a strict seperation of concerns, and want to be as flexible as possible (e.g. exchange the ORM later) while still reducing the amount of code.
It took me weeks to figure out an appropriate architecture, and although my latest approach seems to fit my requirements I'm still not completely convinced, that this way will be the best and is technically possible.
Here is how my solutions-explorer looks like:
MyCompany.MyApplication.Entities
Class library - project, which contains only the domain (business) objects, such as Customers, Adresses, etc. These are POCOs with the [Serializable] - attribute, but do not any other code. All properties are marked as virtual, so that classes could derive and overwrite the properties.
MyCompany.MyApplication.DataAccess
Class library - project, which contains the nHibernate - specific code (Sessions) to load, save and delete the domain objects. This project has references to the Entities-project and also to the nHibernate-libraries.
MyCompany.MyApplication.Core
Class library - project, which contains the business logic, and often just maps the methods form the DataAccess - project, such as GetAllCustomers, SaveCustomer, etc.
It has references to the Entities-project and the DataAccess-project.
MyCompany.MyApplication.Web
Web-application - project, which hosts the silverlight-client-app and also the WCF-services to communicate with the client-side. To expose the domain-objects to the client-side, these classes are derived and all the properties are overwritten and marked with the [DataMember] - attribute. It has references to the Entities-projects and the Core-projects.
MyCompandy.MyApplication.Silverlight
Sivlerlight 3.0 - project, which represents the userinterface. It has only service-references to the WCF-Services exposed by the Web-project. The actual domain-objects aren't accesssible, but the auto-generated proxy-classed replace them.
Please tell me, what do you think about this architecture, and if there are any conflicts! Further question: Is there any way, to avoid the properties of the domain-objects being virtual and the need to overwrite them in order to make them accessible trough WCF?
Best regards,
Daniel Lang
Daniel, you are not going to get around the nhiberante requirement of virtual properties. Have you thought about using Dto's?