How to create a platform ontop of CSLA? <-- if in case it make sense

Here is the scenario, I'm developing an application using csla 3.8 / c#.net, the application will have different modules. its like an ERP, it will have accounting, daily time record, recruitment etc as modules.

Now the requirement is to check for common entities per module and build a "platform" (<- the boss calls it that way) from it. for example, DTR will have an entity "employee", Recruitment will have "Applicant" so one common entity that you can derive from both that can be put in the platform is "Person". "Person" will contain typical info like name, address, contact info etc.

I know it sounds like OOP 101. the thing is, i don't know how i am to go about it. how i wish it was just a simple inheritance but the requirement is like to create an API of some sort to be used by the modules using CSLA.

in csla you create smart objects right, inhe开发者_运维百科riting from the base classes of csla like businessListbase, readonlylistbase etc. right? what if for example i created a businessbase Applicant class, it will have properties like salary demand, availability date etc. now for the personal info i will need the "Person" from the "platform" and implement it to the applicant class.

so in summary i have several questions:

1. how to create such platform?
2. if such platform is possible, how will it be implemented on each module's entities? (im already inheriting from base classes of csla)
3. if incase 1 and 2 are possible, does it have advantages on development and maintenace of the app?

the reason why I'm asking #3 is because the way i see it, even if i am able to create a platform for that, i will be needing to define properties of the platform entity on my module entities so to have validation and all.

---

You are correct about inheriting from the base classes.

1. I would start by designing your base entity without including any relationships. Then I would create your classes that inherit from your newly created entity, and add child properties that pull from the database (via a FK relationship) from the parent entity. I would also recommend checking out our CSLA 3.8.2 templates. They come in both a VB.NET and a C# flavor and will make this task much easier.
2. Yes this is possibly, just follow the steps outlined in #1.
3. I'm not sure on the advantages or disadvantages but it should be easy to maintain in the future. Your derived classes can add rules on top of/have complete control over the rules of the base classes.

Thanks -Blake Niemyjski (Author of the CodeSmith CSLA Templates)

---

the main purpose of the "platform" entities or what we call it now the Generics BOs is for code reuse so when we add modules in the future like accounting or purchasing we have those Generic modules at our disposal.

In the end, my solution was to just determine the Objects that would be used by multiple modules and separate it in a different project so other modules will just be using that project when they need an object from it.

as for my first example the applicant (for recruitment), employee (daily time record) and person ("platform"). what happened was Person was put on the generic BO proj. and both applicant and employee just uses person BO as a child property.

Thanks for the reply Blake. btw, we are really using codesmith for this one. thanks for the suggestion still. Cheers!