Re: Shared Models in Different Modules

Jens,

On Mon, May 5, 2008 at 9:06 AM, pakmannen <jens.ljungblad@...> wrote:

I put off replying to this mail and then forgot all about it, sorry. :-)

bradley.holt wrote:
>
> Assuming you do, in fact, need to add a cross-module
> dependency you can always use the design principle of programming to an
> interface (or an abstract class, this doesn't have to be applied
> literally). This way you
> can have a dependency on *a* User module instead of *the* specific User
> module (for example) you happen to be using at the moment. Of course, this
> leaves open the question as to where the interfaces (or abstract classes)
> for the module should live because they can't live in the module itself as
> this would defeat the purpose. Anyone want to take a crack at this
> problem?
> I have a few ideas but I'm interested to hear if anyone else has found a
> solution to this problem.
>

That's an interesting approach. No idea if it would actually work, but it's
always fun to speculate about these things. :-P I'd be interested to hear
your ideas on placement. I suppose a module could have a configuration file
or similar where those things could be set.

In my other (non-PHP) job I am currently working with a .NET dependency injection framework called the Composite UI Application Block (CAB). The CAB has an interesting approach to cross-module dependencies. For every module you create, you also create an "interface" version of the module where your interfaces and/or abstract classes live (from now on I'll just say "interfaces" but I mean both interfaces and/or abstract classes). Any other modules that have dependencies on your module actual depend on the interfaces in the "Interface" version of the module. For example, ModuleA has all your implementation code and ModuleA.Interface has all of your interfaces. ModuleB references the interfaces in ModuleA.Interface, *not* in ModuleA itself. This setup strictly enforces the concept of programming to an interface. In other words, your contracts are defined in ModuleA.Interface and this leaves you free to change the implementation code in ModuleA as long as you don't break the contract (or you can renegotiate the contract through refactoring). Of course, this setup works best with dependency injection which we don't currently have in ZF. You can still do this manually without dependency injection (using Zend_Registry or manually instantiating dependencies but declaring the type as the interface type), but you need to be a little more careful about not introducing implementation dependencies.

Applying this concept to ZF, there are a few options as to where the equivalent ModuleA.Interface could live. You could literally create two different modules, one for your implementation code and one for your interfaces. However, this probably doesn't make a lot of sense within the context of ZF as these are MVC modules and since the "Interface" module wouldn't have any implementation code it also wouldn't have any action controllers which would be somewhat odd.

A simple option would be for all of your interfaces to simply live in your module. This is a generally a good idea anyways if you want to follow the design principle of programming to an interface. However, it doesn't solve the initial goal of being able to swap out implementation modules since your interfaces live in your module. But, this is probably "good enough" for most situations.

Probably the best option would be to define the interfaces in a component in your library directory. Then, you can write your implementation code in your module. Assuming you write all of your cross-module dependencies based on the interfaces in your component, you can now easily swap out different implementation modules. For example, define a "Blog" component that has all of the interfaces that define blog-like functionality (or at least the interfaces that other modules would need access to). Next, create a "blog" module that implements the interfaces in your "Blog" component. You now have relatively clean cross-module dependencies. You also have the added-benefit if being able to create a better "blog" module in the future (let's call it "blogreloaded") and replace your old "blog" module with a small amount of work (assuming you were good about basing your dependencies on the interfaces in the "Blog" component and not the "blog" module itself).
   
 

bradley.holt wrote:
>
> If you find yourself introducing a lot of cross-module dependencies then
> perhaps you would be
> better of creating components instead and then using these components from
> within your modules.
>

I agree. I tend to favour compontents as often as it makes sense.

bradley.holt wrote:
>
> I would like to have some more guidance from Zend here on best practices
> for
> writing MVC modules. If lots of people started following the same
> practices,
> we could end up with a situation where there a lot of well-written,
> modular
> applications out there that can be wired up to quickly build your
> application. For example, grab a wiki module and a blog module and throw
> them into a custom Zend Framework application and quickly have a website
> with all of these features integrated. Maybe I'm dreaming here :-)
>

I think you are ;-) But seriously, other frameworks do this with various
success. Symfony for instance. It's a tricky area.

Yes, it's definitely a tricky area. I think the design principle of programming to an interface could help with this. Using the suggestion I just made about defining interfaces in a component and implementation in a module, people could work together to define what parts of , say, a blog or wiki application need to be exposed for cross-module dependencies. The interfaces for this could be defined in commonly distributed components (perhaps even provided as part of ZF). Then, individuals can decide exactly how they want to implement a blog or wiki (again, these are just examples, you can apply this to any type of application) and write their own modules based on these components. Basically, the idea is by separating out interface definitions from implementation definitions it is more likely you can get a bunch of people on the same page while still leaving implementation details up to individual programmers. Perhaps I'm still dreaming here :-)
 

Jens Ljungblad
--
View this message in context: http://www.nabble.com/Shared-Models-in-Different-Modules-tp14117646p17061249.html

Sent from the Zend MVC mailing list archive at Nabble.com.

--
Bradley Holt
bradley.holt@...