小编dev*_*yst的帖子

最近我们讨论了类中的数据和行为分离.通过将域模型及其行为放入单独的类中来实现数据和行为分离的概念.
但是,我不相信这种方法的假定好处.虽然它可能是由一个"伟大的"创造的(我认为它是Martin Fowler,虽然我不确定).我在这里举一个简单的例子.假设我有一个Person类,其中包含Person及其方法(行为)的数据.

class Person
{
    string Name;
    DateTime BirthDate;

    //constructor
    Person(string Name, DateTime BirthDate)
    {
        this.Name = Name;
        this.BirthDate = BirthDate;
    }

    int GetAge()
    {
        return Today - BirthDate; //for illustration only
    }

}

现在,将行为和数据分离到单独的类中.

class Person
{
    string Name;
    DateTime BirthDate;

    //constructor
    Person(string Name, DateTime BirthDate)
    {
        this.Name = Name;
        this.BirthDate = BirthDate;
    }
}

class PersonService
{
    Person personObject;

    //constructor
    PersonService(string Name, DateTime BirthDate)
    {
        this.personObject = new Person(Name, BirthDate);
    }

    //overloaded constructor
    PersonService(Person personObject)
    {
        this.personObject …

我正在将旧的Web窗体应用程序扩展/转换为全新的MVC应用程序.扩展既包括技术也包括业务用例.遗留应用程序是一个完善的数据库驱动设计(DBDD).因此,例如,如果您有不同类型的员工,如操作员,主管,商店管理员等,并且您需要添加一个新类型,您只需在几个表中添加一些行,瞧,您的UI自动拥有要添加的所有内容/更新新类型的员工.然而,层的分离并不是那么好.

新项目有两个主要目标

• 可扩展性(适用于当前和未来的管道要求)
• 性能

我打算使用域驱动设计(DDD)创建替换数据库驱动设计(DBDD)的新项目,同时牢记可扩展性要求.但是,如果将其与传统DBDD应用程序的性能进行比较,从数据库驱动设计转向域驱动设计似乎会对性能要求产生相反的影响.在遗留应用程序中,来自UI的任何数据调用都将直接与数据库交互,并且任何数据都将以DataReader或(在某些情况下)DataSet的形式返回.

现在有了严格的DDD,任何数据调用都将通过业务层和数据访问层进行路由.这意味着每次调用都会初始化业务对象和数据访问对象.单个UI页面可能需要不同类型的数据,这是一个Web应用程序,每个页面都可以由多个用户请求.MVC Web应用程序也是无状态的,每个请求都需要每次都初始化业务对象和数据访问对象.因此,对于MVC无状态应用程序而言,DBDD更倾向于DDD以提高性能.

或者在DDD中有一种方法可以实现DDD提供的可扩展性和DBDD提供的性能？

我是 PowerBI 的新手。我正在尝试实现“应用程序拥有数据”，即在我的 Web 应用程序中嵌入报告。我正在关注这篇文章https://docs.microsoft.com/en-us/power-bi/developer/embed-sample-for-customers

我已经下载了示例应用程序，我正在按照步骤操作。但是目前我被困在 WorkspaceId 上。在哪里可以找到workspaceId？我查看了 PowerBI 中的所有屏幕和关联的 Azure 帐户，但找不到它

我没有使用任何ORM.因此,我正在讨论"保存"方法是否实际上属于业务域实体,还是应该在某些服务中进行抽象,这些服务将通过业务域实体进行保存？

例如

class Employee
{
    string Name;
    DateTime Birth;

    GetAge()
    {

    }

    Save()
    {
    }           

}

要么

class Employee
{   
    string Name;
    DateTime Birth;

    GetAge()
    {

    }


}

SomePersistenceService
{
    Save(Employee emp)
        {
        }
}

我需要在SQL Server中创建一个查询,其中搜索条件将包括/排除基于用户输入的表.

说我有两个表,TABLE_A并TABLE_B用列KEYCOLUMN_A,并COLUMN_A在TABLE_A与列FKCOLUMN_B和COLUMN_B的TABLE_B.

和查询一样:

SELECT TABLE_A.* FROM TABLE_A, TABLE_B WHERE TABLE_A.KEYCOLUMN_A = TABLE_B.FKCOLUMN_B
AND TABLE_A.COLUMN_A LIKE '%SEARCH%' AND TABLE_B.COLUMN_B LIKE '%SEARCH2%'

现在,如果用户没有输入SEARCH2,我不需要搜索TABLE_B.但这意味着一个IF ELSE条款.而作为"可选"表中查询数量的增加,排列组合也将增加,会有许多IF和ELSE报表.

相反,我决定保持声明不变.因此,如果SEARCH2为空,则查询将有效地变为:

SELECT * FROM TABLE_A, TABLE_B WHERE TABLE_A.KEYCOLUMN_A = TABLE_B.FKCOLUMN_B
AND TABLE_A.COLUMN_A LIKE '%SEARCH%' AND TABLE_B.COLUMN_B LIKE '% %'

SQL优化器能够识别出LIKE %%与删除条件本身一样好吗？

我正在构建一个 3 层架构，其中包含表示层 (PL)、业务逻辑层 (BLL) 和数据访问层 (DAL)。
传统的 3 层架构逻辑指出，BLL 应充当 PL 和 DAL 之间的中介。PL 甚至不应该知道数据库的存在，而 DAL 不应该知道 BLL 或 PL 的存在。

实施上述操作将在 3 个不同的物理项目之间创建以下依赖关系，如下所示

• PL 项目 -> BLL DLL 参考
• BLL 项目 -> DAL DLL 参考
• DAL 项目 -> 无参考

然而，通过在 BLL 中定义接口供 DAL 实现并通过构造函数注入使用 DI，在 BLL 和 DAL 之间应用 IOC 的概念将改变依赖关系，如下所示

• PL 项目 -> BLL DLL 参考、DAL DLL 参考（用于具体类型到 BLL 对象构造函数的 DI）
• BLL 项目 -> 无参考
• DAL 项目 -> BLL DLL 参考（用于 BLL 接口的实现）

那么IOC和传统的三层有冲突吗？

理想情况下，我希望实现以下目标，同时通过 DI 维持我的 …

我知道聚合根是唯一将由客户端加载的对象，聚合根内对象的所有操作都由聚合根完成。按照相同的约定，应该为聚合根定义一个存储库接口，并且聚合根内任何对象的任何持久性操作都应该由与聚合根对应的“聚合根存储库”完成。这是否意味着只有 Aggregate Root 对象应该传递到“Aggregate Root Repository”以进行与 Aggregate Root 的子对象相关的操作？

让我举个例子吧。

假设您有一个 School 对象和 Student 对象。由于学生不能没有学校，（你可能会说学生可能已经离开学校，在这种情况下他/她不再是学生），所以我们有

class School
{
    string SchoolName;
    IList<Student> students;
}

class Student
{
    string StudentName;
    string Grade;
    School mySchool;
}

学校是这里的聚合根。现在假设我们要为持久性操作定义一个存储库。

下面哪个是正确的？

1)

interface ISchoolRepository
{
    void AddSchool(School entity);
    void AddStudent(School entity); //Create a School entity with only the student(s) to be added to the School as the "students" attribute
}

2)

interface ISchoolRepository

{
    void AddSchool(School entity);
    void AddStudent(Student entity); //Create a Student entity. The Student …

在SQL Server 2000中

我有一个查询

SELECT DISTINCT A.COLUMN1, B.COLUMN2 FROM TABLEA A, TABLEB B WHERE 
A.KEY_ID = B.FK_ID

ORDER BY CASE @ORDER_NAME
         WHEN 'COL1' THEN COLUMN1
         WHEN 'COL2' THEN COLUMN2
         ELSE
         COLUMN2
         END ASC

这里A.COLUMN1是varchar(50),B.COLUMN2是datetime.当@ORDER_NAME的值为'COL2'时,此查询工作正常,即当order by是datetime类型但是当我使用'COL1'时,它会给出错误'语法错误从字符串转换datetime'.

我认为这是因为SQL Server正在尝试将所有列转换为datetime类型.但我找不到动态排序列的替代语法.由于性能问题,EXEC是不可能的

我需要提一下,我试图避免分支,否则上述也可以通过IF ELSE条款完成.

我在一个MVC项目中工作,该项目包含常规MVC控制器和Web API控制器.最初,我使用自定义用户表实现了表单身份验证.但现在我计划使用新的ASP .NET身份,并从基于cookie的表单身份验证更改为基于声明的身份验证和授权.我已经有一个包含自定义字段的表的数据库.所以我需要自定义ASP .NET身份以便与我的表一起工作任何人都可以指导我如何实现这一目标吗？

编辑:

在回复FKutsche时,这是我的用户表.我只保留了重要的列.

用户表

用户身份

用户名

密码

UserTypeId

用户类型表

UserTypeId

用户类型

列名是自解释的,所以我没有描述它们.用户表在UserType表的UserTypeId列上具有外键.

遵循 CQRS（命令查询职责分离）的概念，我在我的 MVC 应用程序中直接引用 DAL，并通过 ViewModel 进行所有读取。然而，我的一位同事问我，当阅读时必须应用任何业务逻辑时，你会怎么做。例如，如果您需要在如下场景中计算百分比值：

//Employee domain object
class Employee
{
    string EmpName;
    Single Wages;
}

//Constant declared in some utility class. This could be stored in DB also.
const Single Tax = 15;

//View Model for the Employee Screen
class EmployeeViewModel
{
    string EmpName;
    Single GrossWages;
    Single NetWages;
}


// Read Facade defined in the DAL
class ReadModel
{
    List<EmployeeViewModel> GetEmployeeList()
    {
        List<EmployeeViewModel> empList = new List<EmployeeViewModel>;
        string query = "SELECT EMP_NAME, WAGES FROM EMPLOYEE";      
        ...
        .. …

我试图定义一个可以返回数据列表的通用方法.我想让它变得灵活,允许返回DataTable或List <T>.例如

 *SomeGenericDataTypeInterface* GetResult(IDictionary IDictParams);

DataTable和List似乎没有任何共同的基本接口.这有可能吗？