Modular Programming

Question

Modular Programming

Navigation

#1 by (3 votes)

4

Something quite commonplace in developing business systems and how we meet different requirements, these requirements are often not used by certain customers, for example, when a company that operates in the field of sales would not need the module of service which is used by companies providing services. This brings up the need for modular software development to meet these requirements.

The application is marketed in modules - the customer can buy the sales module, but not the industrial control module.
The application can be developed by separate teams - each team develops an independent module.
Modules are only loaded when the user has access to it.
The application does not need to be fully distributed when a module changes
We can create new modules and add them to the system without having to change the other modules

With a little reading on the subject, we can soon reach the Managed Extensibility Framework (MEF)

Managed Extensibility Framework or MEF is a library for creating lightweight and extensible applications. It allows application developers to discover and use extensions without any necessary configuration. This also allows extension developers to encapsulate the code easily and avoid rigid, fragile dependencies. MEF not only allows extensions to be reused in applications, but also across applications.

My question is whether or not to use MEF?

Are there other alternatives?

NOTE: Examples are always welcome.

c#

asked by anonymous 17.12.2014 / 12:55

1 answer

Running program in the background Referencing the table itself in Mysql is correct?

score 3 · Accepted Answer

Pablo, I've been working with this for a long time already using C # in an interdependent system! I think even though we are interdent, we have managed to modu- late the system in general.

We have our own methodology for building our specializations by modules, not exactly as shown in the Microsoft on the subject.

Our system started all modular, but over time it went (naturally) to being fully integrated. We have many customers who still buy only a few modules. But there comes an intrinsic need: Integrations !

Example: Buying modules where you are an expert

Here's a case: You're a specialist in stock control and logistics. Your system is amazing in these modules, but it sucks to make incredible HML5 presentations with millions of photos updated every week.

If a customer comes to you for expertise in this matter, you'll probably need several integrations: Inbound invoices to know what's going into inventory (purchases and stock returns), an up-to-date materials orders and stock reservations and another for invoices to exit the inventory. Maybe even another integration for notification of broken materials.

Modular Sales

Nowadays we are already more mature with regard to sales of modules in separate. Although we have modules and specializations (for example, we sell the billing module, but in Brazil we invoice one way, in Chile in another, etc.), we also have a solid integration mechanism for all the modules.

Of course, there is an interdependence between all the modules. Even if the customer wants to buy only one module or another, it is necessary to map the interdependencies and make sure that they get a solid product.

Specialized Modular Mechanism

The way we do today is as follows: Our modules are loaded one by one by common interfaces distributed in the system. There is a Factory of these interfaces that verifies, every time it is called, whether the module has already been loaded or not, if it is not it loads (each of our modules is in a module-specific and specialization DLL for easy visualization) .

We use a lot of reflection for these cases. It's worth a look. We have a common DLL that defines what is an object of type Modulo and common interfaces that this object must implement. Then these objects can be instantiated and used when needed.

You can call the billing module at any point in the system to bill an order, for example ModuloFaturamento.FaturarPedido(codigoPedido); . If the customer owns the module, the order is actually invoiced. Otherwise, a stub can be implemented to do nothing or an integration can be done with a request for an external system (eg SAP).

Summary

I believe that modularisation is quite feasible, but there is considerable expense in integrations when the client does not want all the modules. Try to specialize in the modules in which your current customers give more importance. Understand all of it and become reference. Others will begin to come more naturally if necessary.