我有一个解决方案分为两个项目：一个包含所有模型类的类库（让我们称之为 Business ）和一个ASP.Net MVC项目。
我的商业类是通用的，适用于多种类型的项目。因此，他们不会将数据注释 / 关联包含在其他类中，只包含成员变量 / 属性< /强> / 构造
使用代码优先方法，我应该如何设计我的ASP.Net模型以使用我的业务模型。
我最初的教程是将商家类设置为部分类，然后通过添加必要的数据注释 / 关联来覆盖我的属性。我无法做到这一点，因为我们正在处理两个独立的项目。
我还在想我可以使用继承。我的ASP.Net模型可以继承Business类，我可以添加数据注释 / 关联。这看起来有点混乱和不合逻辑，因为我需要在这个新的子类中定义我的所有构造函数。
有干净利落的聪明方法吗？
编辑：
我的商家类通过在属性设置器中抛出异常来进行验证。我的第一个设计是创建我自己的自定义数据注释，它将捕获我的二传手抛出的异常：
public class SetterBasedValidation : ValidationAttribute
{
string m_errorMessage = null;
public SetterBasedValidation(string errorMessage)
{
m_errorMessage = errorMessage;
}
protected override ValidationResult IsValid(object value, ValidationContext validationContext)
{
try
{
Type type = validationContext.ObjectType;
PropertyInfo property = type.GetProperty(validationContext.MemberName);
property.SetValue(validationContext.ObjectInstance, value);
}
catch (Exception)
{
return new ValidationResult(m_errorMessage);
}
return ValidationResult.Success;
}
}
然后我需要一种方法在我的ASP.Net模型类中使用我的自定义数据注释。这会给我我想要的结果：
答案 0 :(得分：2)
将相同的类用于多种用途的想法并不是很好。通常，业务类面向（负责）业务逻辑。另一方面，查看模型，因为这通常是您在ASP.NET MVC Models文件夹中所拥有的，负责支持MVC应用程序的视图。最后有数据类（有些称为DTO），它们是DAL的一部分。
因此，从前到后你应该有数据类，业务类，最后是查看模型，它们构成绝对最小值适用于中型到大型网络应用。即使是小型应用也可以从这些分离中受益。
现在您可以回想一下 SOLID 的第一个字母，即单一责任原则，其中说明：
一个班级应该只有一个改变的理由。
（更多关于单一责任原则here。）
您要做的是为您的业务类分配两个角色，即业务和演示，视图模型。因此，比方说，您想要涵盖一些新的业务功能，那么，您的视图模型肯定会受到影响。另一方面，如果要添加一些与视图函数相关的函数（您的情况），您的业务逻辑实现可能会受到威胁。这就好像你将它们放在procrustes bed中一样。
更糟糕的是，您将这些类称为“通用”，因此倾向于在应用程序的其他部分（可能是DAL）中使用它们。只是不要。
在你的例子中清楚可见的是，一旦你开始与对抗基本设计原则，你就会陷入设计麻烦来构建你的应用程序。
所以，坚持众所周知的事情：
以这种方式分离您的应用将使您的生活更轻松。