I'm getting started using Lagom in Java and have a need to write a custom (de)serializer. I've read through the documents and understand the roles of the NegotiatedSerializer, MessageSerializer, SerializerFactory etc. What I don't understand is in which package it is canonical to define the class. I've looked at the Chirper sample and see that there are often concrete model definitions alongside the *Service interfaces in the various *API modules, but there are no examples of custom Serializers. Thanks for the help!
Serializers for messages (request bodies, response bodies, and messages published to a topic) should be part of the service's api module. Serializers need to be used both by clients of the service and by the service implementation itself. This makes them part of the service interface or API.
Serializers for persistence (commands and replies, persistence events, entity state) should be defined in each service's impl module. They are details of the internal implementation and should not be exposed to clients.
Beyond those broad guidelines, the way you organize your package structure is really up to you. Some projects use a single package for the API and a different one for the implementation. Others might divide each into sub-packages, though as services should generally stay pretty small and focused, this might be overkill. You should arrange the packages in a way that makes sense for your project and organization.
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.
I read this article and saw many people commented that do not use Castle Windsor to implement IDependencyResolver in ASP.NET MVC3 and stick with a custom IControllerFactory. Basically my questions now are:
Do not use Castle Windsor to implement IDependencyResolver. Is this still true in ASP.NET MVC 4 ?
If 1 is the case. Can any other DI container (Unity, StructureMap) has the same problem as Castle Windsor? Can I use any alternative?
Thanks a lot
EDIT
Sounds to me that Castle Windsor should NOT be used to implement IDependencyResolver. I have decided to use some other DI container, such as StructureMap
There is no difference between MVC3 and MVC4 in regards to IDependencyResolver, other than the fact there is a separate resolver for WebAPI.
In my opinion, Mike Hadlow is a bit too caustic on this subject, and many other people have jumped on the bandwagon without truly considering why.
Yes, it's true that Castle Windsor has a specific object lifestyle (ie lifetime management object) called Pooled that often requires you to call Release on it. And when using this lifestyle, you should probably not use IDependencyResolver because it does not provide access to this Release method (although there are ways around that too).
However, I feel it's generally bad to use this lifestyle in a web application, and you should instead use the PerWebRequest lifestyle, which will automatically release objects at the end of the web request. If this is what you are using, then there is no problem with using IDependencyResolver with Castle Windsor.
Why do I think Hadlow is too caustic? Well, because he bases his entire argument on this:
"That’s right, no ‘Release’ method. You can provide a service from your IoC container, but there’s no way to clean it up. If I was going to use this in Suteki Shop, I would have a memory leak of epic proportions."
He then goes on to reference Krzysztof Koźmic's article regarding lifestyle management, but neglects to reference his followup article which I will do here:
http://kozmic.net/2010/08/27/must-i-release-everything-when-using-windsor/
Note what he says here:
"Since as I mentioned in my previous post, Windsor will track your component, it’s a common misconception held by users that in order to properly release all components they must call Release method on the container."
He goes on to talk about various other aspects as well, but in general, I don't think most people will be using Pooled or Transient objects that required disposal in a web application. And if you do, then you should know not to use IDependencyResolver then. Otherwise, you should have no problems.
I know I will probably get a lot of grief from people arguing otherwise, but I simply do not see this as the end of the world issue that people like Hadlow seem to think it is, since there are so many alternatives, and workarounds even when you do need to call Release.
Besides all this, using a lifestyle that requires calling Release means extra work for you, the developer. You now have to manage the object lifetimes and remember to dispose of objects, and failing to do so creates memory leaks. This is, essentially, nullifying the benefits of garbage collection in my opinion. I only ever use transient objects with things that do not need disposal, and I never use pooled objects.
By the way, I may be wrong, but I don't think any other container has this problem. This leads me to the conclusion that it's Windsor that is broken, rather than MVC, when every other container out there seems to not have an issue with this. Windsor likes to stubbornly hang on to its version of reality though, so YMMV.
The advice not to use IDependencyResolver is silly, because it can be used with Castle Windsor, even though the interface lacks a release method. The solution is simply to let the IDependencyResolver implementation cache each requested instance (in a cache bounded to the web request, using HttpContext.Items for instance). At the end of the web request all cached instances (usually just a few) can be released.
To be able to release all instances at the end of the web request, you should either register an Request_Ends event in the global.asax or register a HttpModule that does this.
You can call this a workaround, but not using the IDependencyResolver is not really an option, since it is too deeply integrated with MVC. Besides, other containers (such as Ninject and Simple Injector) use this same approach (using an HttpModule) to 'release' instances.
It's unfortunate though, that there isn't an official NuGet packages for omtegrating Windsor with MVC, since now you'll have to implement this yourself. All other frameworks do have such package btw. But again, it isn't that hard to implement this yourself.
Other IoC containers already show that it is possible to implement release as an implementation detail and you don't need Release as part of the IDependencyResolver contract. The MVC designers actually did the right thing by removing such method from the API.
While I agree implementing IDependencyResolver is possible and not terribly difficult.. and yes, depending on the lifestyles at play, explicitly Release()'ing may not matter... and yes, there are ways to force a Release() by caching the instance somewhere as well as other subtle tricks - I think this is alot to leave to interpretation and can be problematic and hard to track down. Understanding when Windsor is going to track an instance isn't always immediately obvious (i.e. if the component has decommission concerns vs. not, lifestyle, etc.). One of the core value-add's of IoC is to centralize the responsibility of object creation and instance management. To properly do that and have separation of concerns - you need to have an architecture that you can trust will serve you well in call scenarios and that IMO means having a iron clad answer for Release()'ing instance of all flavors. My advice is to always implement a design that will allow Release to be called - especially on roots (i.e. a Controller).
The final argument against IDependencyResolver is you have to register a number of MVC system components if you integrate at this level. That's too intimate of a dance between my app and the framework beneath it for my taste. IControllerFactory gives a much more targeted integration point, you don't have to register MVC system components and you get a Release() hook. So, unless you want to override MVC System components, I see very little reason to implement IDepedencyResolver over IControllerFactory. I see the opposite argument in fact. I personally wised up to this on this thread over here which shows both approaches.
Hope this helps
I see files like Castle.DynamicProxy.dll or Castle.Core.dll or Castle.Model.dll and various others similar in projects that are supposed to be simple, noob's introduction to nHibernate. What does this Castle stuff have to do with nHibernate? Is this unadvised muddying up the waters by the tutorial authors or does nHibernate really require this sort of extra hoops jumping just to get the basics running?
NHibernate uses proxy objects to achieve lazy loading and uses the Castle DynamicProxy module. This is the reason your entity properties need to be virtual. Because NHibernate creates proxy classes that intercept calls to your properties.
I have come across fluent API's while studying DSLs.
I have searched a lot on fluent API's...the basic conclusion which I could draw was that fluent a API uses method chaining in order to make the code fluent.
But I cannot understand - in object oriented languages we can always create an object and can call the methods related to it. Then how is a fluent API different? What other features does a fluent API add?
With a fluent interface you write methods that return the object that the method was invoked on (usually self or this) and handle traditional return values as a state change in that object. If you look at say some of the Javascript libraries that use a fluent interface it makes it far easier to deal with lists and nulls as they can be handled the same way you would a single object. The disadvantage of fluent interfaces is that they tend to create monolithic god objects that have a whole heap of responsibilities.
I wouldn't want them to be used everywhere (because of the god object problem) but they are nice from time to time.
Your question is answered in the originating Fluent Interface blog post by Martin Fowler. The point is that the fluency in fluent API comes from the domain of a domain specific language, not only method chaining.
Fluent API is an advanced way of specifying model configuration that covers everything that data annotations can do in addition to some more advanced configuration not possible with data annotations.
And Web API is a programming interface/application type that provides communication or interaction between software applications.