A specific problem with architecturing a part of our application

Firstly, I’ll try to describe the real world model of what we are trying to express in C# code.

We have a device called M100. It’s purpose is to readwrite data frominto cards (plastic or ULTRALIGHT cards such as MIFARE). It can be with one up to 3 antennas (the device readwrite data through antenna). One of antennas is internal (so card can be put on the device surface and the device will be able to perform readwrite operations), the other are external. Let’s consider the usual situation. We have a point of service terminal. M100 reside inside the terminal and it has two external antennas wich are placed over a tract of cards dispenser. Cards dispenser is another device which is responsible for accepting and dispensing cards for performing readwrite operations by M100. So, card dispenser takes the card from the user, move it to the readwrite position and after that M100 can perform readwrite operations. M100 can be equipped with only one (internal) antenna. So we have to main cases: with and without card dispensers.

We have one application that interacts with dispensers and the other uses M100 without card dispensers.

We developed M100Provider with it’s interface IM100Provider. This is the low-level class which interacts with M100 directly, passes commands through COM-port.

We have a higher level-operations such as AuthorizeOperator, WriteTicket, ReadCard (all this operations require M100) so we developed M100Communicator class (maybe the name does not reflect it’s intention at the time, but we will think about the name a bit later). M100Communicator is a singleton. Because we need to manipulate card dispensers to accept and dispense users cards M100Communicator interacts with CardDispensersManager class. We haven’t decide yet wil it be composed into M100Communicator or will it be a singleton (it seems like it’s a singleton).

All these operations are have to perform in a kind of a unified way:

Block the current object.
Check if there are some dispensers configured
If they are – pass to them a command to open the tract for card acception.
Pass to M100 a command to search a card through specified antennas.
When the card was found, perform readwrite operations.
Dispense card back to the user.

Here are the problems we are faced:

Considering that M100Communicator sometimes doesn’t require CardDispensersManager we are forced to check it’s state to null reference everywhere (and it will be quite strange to have a special case CardDispensersManager which will return meaningfull responses while there are no dispensers!).
M100Communicator and CardDispensersManager have to be initialized from the start of the system so it’s unclear how to update the configuration of CardDispensersManager and M100Communicator and how to communicate with CardDispensersManager directly when we want to close ports and stop communication with dispensers explicitly, because it will be very strange to expose dispensers API through M100Communicator. (yes we have the requirement to be able to access dispensers API from everywhere, so we think that CardsDispenserManager has to be a singleton).

Your problem is exactly same kind of problem this exercise on software design describes.

Instead of designing the code around specific device, you should design abstraction that describes process of reading a card. Then, this abstraction can be concretized to specific devices. If you design you software this way, the problems you are facing will be solved during creation of the concrete objects for specific application.

Filed under: softwareengineering - @ 07:12

Thẻ: .net, architecture, c++, domain-driven-design, enterprise-architecture

A specific problem with architecturing a part of our application

Firstly, I’ll try to describe the real world model of what we are trying to express in C# code.

We have one application that interacts with dispensers and the other uses M100 without card dispensers.

We developed M100Provider with it’s interface IM100Provider. This is the low-level class which interacts with M100 directly, passes commands through COM-port.

All these operations are have to perform in a kind of a unified way:

Block the current object.
Check if there are some dispensers configured
If they are – pass to them a command to open the tract for card acception.
Pass to M100 a command to search a card through specified antennas.
When the card was found, perform readwrite operations.
Dispense card back to the user.

Here are the problems we are faced:

Considering that M100Communicator sometimes doesn’t require CardDispensersManager we are forced to check it’s state to null reference everywhere (and it will be quite strange to have a special case CardDispensersManager which will return meaningfull responses while there are no dispensers!).
M100Communicator and CardDispensersManager have to be initialized from the start of the system so it’s unclear how to update the configuration of CardDispensersManager and M100Communicator and how to communicate with CardDispensersManager directly when we want to close ports and stop communication with dispensers explicitly, because it will be very strange to expose dispensers API through M100Communicator. (yes we have the requirement to be able to access dispensers API from everywhere, so we think that CardsDispenserManager has to be a singleton).

Your problem is exactly same kind of problem this exercise on software design describes.

Filed under: softwareengineering - @ 07:12

Thẻ: .net, architecture, c++, domain-driven-design, enterprise-architecture

Thiết kế website giá rẻ

Danh mục

A specific problem with architecturing a part of our application

A specific problem with architecturing a part of our application