如何在CSLA之上创建一个平台? <-- 如果万一有意义的话

发布于 2024-08-24 13:05:24 字数 677 浏览 7 评论 0 原文

这是场景,我正在使用 csla 3.8 / c#.net 开发一个应用程序,该应用程序将具有不同的模块。它就像一个ERP,会有会计、日常记录、招聘等模块。

现在的要求是检查每个模块的公共实体并从中构建一个“平台”(<-老板这样称呼它)。例如,DTR 将有一个实体“员工”,招聘将有“申请人”,因此您可以从两者派生并放入平台的一个常见实体是“人员”。 “Person”将包含典型信息,如姓名、地址、联系信息等。

我知道这听起来像 OOP 101。问题是,我不知道该怎么做。我多么希望这只是一个简单的继承,但要求就像创建某种 API 供使用 CSLA 的模块使用。

在 csla 中,您可以正确地创建智能对象,继承自 csla 的基类,如businessListbase、readonlylistbase 等,对吗?例如,如果我创建了一个业务基础申请人类,它将具有薪资需求、可用日期等属性,现在对于个人信息,我将需要“平台”中的“人”并将其实施到申请人类。

总而言之,我有几个问题:

  1. 如何创建这样的平台?
  2. 如果这样的平台是可能的,它将如何在每个模块的实体上实现? (我已经从csla的基类继承)
  3. 如果情况1和2是可能的,它对应用程序的开发和维护有优势吗?

我问#3的原因是因为我认为,即使我能够为此创建一个平台,我也需要在我的模块实体上定义平台实体的属性,以便进行验证和所有操作。

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, inheriting 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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

遗失的美好 2024-08-31 13:05:24

关于从基类继承,您是正确的。

  1. 我将从设计您的基本实体开始,不包括任何关系。然后,我将创建从新创建的实体继承的类,并添加从父实体的数据库(通过 FK 关系)提取的子属性。我还建议您查看我们的CSLA 3.8.2 模板。它们具有 VB.NET 和 C# 风格,将使这项任务变得更加容易。
  2. 是的,这有可能,只需按照#1 中概述的步骤操作即可。
  3. 我不确定优点或缺点,但将来应该很容易维护。您的派生类可以在基类的规则之上添加规则/完全控制基类的规则。

谢谢
-Blake Niemyjski(CodeSmith CSLA 模板 的作者)

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)

痴情 2024-08-31 13:05:24

“平台”实体或我们现在所说的通用 BO 的主要目的是为了代码重用,因此当我们将来添加会计或采购等模块时,我们可以使用这些通用模块。

最后,我的解决方案是确定多个模块将使用的对象并将其分离到不同的项目中,以便其他模块在需要其中的对象时仅使用该项目。

对于我的第一个例子,申请人(用于招聘)、员工(每日时间记录)和人员(“平台”)。发生的事情是 Person 被放入通用 BO 项目中。并且申请人和雇员都只是使用人 BO 作为子财产。

感谢布莱克的回复。顺便说一句,我们实际上是在使用 Codesmith 来完成这个任务。还是谢谢你的建议。干杯!

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!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文