7

By modular applications I mean applications in which base functionality and data model can be extended without modifying core application code.

It's a popular approach with eg. open source CRMs like SugarCRM or VTiger.

This approach may be followed in asp.net mvc application using Areas or (portable areas from MVC contrib) which allow adding new controllers and views in separate assemblies, without impacting core dlls.

The problem arises when one wants to extend the base application's data model. It's not possible in any practical sense with entity framework where the model definition is centralized in the Edmx file. This approach doesn't allow adding a new table that would reference some base module table in a new assembly.

I've noticed, that the Orchard CMS achieves full modularity by using nHibernate (which is telling, given they have Microsoft backing and the project was meant as a technology showcase). Nhibernate allows such modularity thanks to the POCO approach. Each entity/table is defined in a separate file which obviously is the way to go with modular applications.

There is, however, a hope with Entity Framework Code Only approach, which generates Edmx model in runtime using POCO definitions. Has anyone tried this approach to distribute the data model's definitions in a separate, pluggable projects?

aaimnr
  • 1,646
  • 1
  • 17
  • 31
  • Seems too limited for the time being, but possibility of such extensibility looks like a good reason to switch. – aaimnr Mar 01 '11 at 16:37
  • This was asked a long time ago, however I would like to know what you did @deadbeef. I'm running into a similar conceptual problem – MrJD Sep 27 '12 at 04:46
  • I haven't achieved such modularity, sticked with central EDMX (it's a horrible solution nonetheless). – aaimnr Oct 12 '12 at 09:20

1 Answers1

3

I have achieved this using EF Code First and a combination of GUI extension points on the core module. It resulted in:

  • Each module is treated as a standalone application (except for GUI)
  • Each module has it's own database (as code first drops & recreates database)
  • Each module may duplicate needed data in another module
  • Each module is a service
  • Each module can extend the GUI through core extension points via an IoC container
  • Modules can communicate with each either via asynchronous messaging (nServiceBus) and synchronous RPC (WCF)

Please note that this is an enterprise application that we designed for SOA.

With EF Code First, if you manage your database manually (ie. don't drop & recreate), you could take some concepts above and simplify it. You may need a custom IDatabaseInitializer to support it but it should be possible.

JarrettV
  • 18,845
  • 14
  • 46
  • 43