Developer

Jan 15, 2013 at 8:25 PM

I am very interested in the project and I like the idea of ​​XAF.

I'd like to contribute to the development.

My English is poor but I am a good programmer.

Have you ever tried to make a client for winrt?

Coordinator
Jan 17, 2013 at 9:13 PM

We have abandonded the XAF model...  We have opted for a Localized Pattern...  ERP DB's get very massive so we have localized each module and create an entity very specific to the requirements of the module...  It allows us to only deal with the subset of data required for the module being developed...  While still allotting for a single entity connection string to manage the multiple entities...  As it would be a night mare to manage 100's of connection strings...

So the entity tree is very tight and specific as it bubbles to the UI XAML  bindings...

Anyways if you are still interested we could definately get you going on a module to take on...

Jan 17, 2013 at 10:33 PM

Sorry but the idea of XAF has trap me and ...

Now I downloaded the source code and I saw the "sample project" with some modules.

Each module has a:

server side:dal layer with a little entity and a service project

client side: domain layer, wpf gui.

I'm interested again and now I'm curios of how to split data/entity of erp in module without interaction from module.

Coordinator
Jan 21, 2013 at 2:36 PM
Edited Jan 21, 2013 at 2:38 PM

I am not sure I understand the question...  The little entity models as you describe them are served up to the Domain layer via WCF Data Service...  The entity objects can then be consumed by the Domain Layer...  The domain has a repository Class that is responsible for all the CRUD interactions using WCF Data Service Calls...  The domain repository is then consumed by the View Models in the WPF Client Layer.   The GUI components are then bound to the View Model objects via XAML Binding...

This pattern is repeated over and over again as more Modules are created... Note a module could be one UI form or multiple UI forms.   So each independant Entity is targeted very specifically to a certian UI or group Of UI's that share the same data requirements...

This optimizes the responsibility of each entity to be nice tight and clean...  Their is nothing more frustrating then grabbing an entity that has 100 + tables chained...  It is slow and is hard to visualize...

But if you keep them small and tight it is very easy to visualize the data and work with it...

In doing this though you have to maintain a sinle connection string to manage all of entities and we do that through a custom config file and when the entities are instatiated they use the cusom config connection string to allow us a single point of change, as we move XERP from db to db...

Of course at some point a UI may require a vast amount of tables requirements.  The data requirements for certain Key components of ERP can become very data intensive and require a lot of tables with a lot of joins...

At that point you could create the Data Requirements as an all inclusive entity to cover the data requirements for the UI or targeted UI's or you could consume multiple entities that may or may not allready exist...

It is also important to note that you may have a table in multiple entities...  That is okay their is nothing wrong with having a table in multiple entities to target multiple data requirements...

The important thing is you have control to shape your entity as big or as little as required for the targeted portion of ERP that you are designing to...

Without creating one giant massive Entity that is to hard to service change and work with...  Breaking it apart allows for multiple developers to work on multiple modules at the same time...

It will revolutionize the idea of using entity...  As most people use entity as a single entity to service their entire project...  This  gets to be more trouble then it is worth as it grows past 100+ tables it becomes a monster to manage...  Keeping it small and tight and having many entities allows for easy visualization and change management of your data requirements as they grow and change...