我正在为中型组织设计这个人力资源系统（基于桌面）。问题是我已经设计了所有表，并计划在VS2008中使用O / RM来生成实体类（这是我第一次使用OR / M;实际上，这是我的第一个“大”项目。 ）我想制作3层的应用程序（公司的一个程序员建议不是3层，但是4层或5层）但是在阅读了很多博客条目和很多问题之后，我意识到这不是很好使用LINQ to SQL很容易做到这一点，因为datacontext的工作原理以及使用LINQ to SQL在层之间传递对象的难度。
可能我只会使用VS2008 ORM生成的实体类，并在部分类中添加任何验证和bussines逻辑。 但那将是2层，还是没有？该应用程序将被10个用户使用，所以我认为2层方法目前不是一个大问题。
未来，将开发基于网络的前端，以便候选人可以在线申请工作。我希望尽可能地扩展它。但事实是，我没有太多时间浪费做出决定，时间不断嘿嘿。
说了这么多，我应该只使用VS2008 ORM生成的实体吗？
所以任何建议或想法都将不胜感激。感谢。
答案 0 :(得分：1)
你在这里提问时，你正在咀嚼很多。 （那里有隐藏的具体问题吗？）
对于图层，我假设您指的是物理边界，即应用程序，app / SOA / WCF服务器，位于SOA服务器上的数据层以及某处的数据库。
为未来设计似乎是一个好主意，但确保在某个地方需要所有这些层。从本质上讲，如果您在某些时候没有通过Internet公开您的应用程序，则不需要基于WCF / SOA的方法。在许多情况下，Web前端可以解决同样的问题。
我不是说你根本不需要那些层，但你可能不会。如果你真的这样做，接缝就是你的朋友。您需要制作“切割点”，以便定义边界。我通常使用存储库模式来使数据访问方法多样化，并使用普通对象（POCO）和通过NHibernate等技术持久化的接口。使用POCO还可以更容易地在以后通过线路传输这些对象，无论是独立的还是部分消息。
创建被调用的服务接口可以巩固您的界限。当您准备好移动跨机器/物理边界时，您只需在服务实现中创建边界。
答案 1 :(得分：1)
这听起来确实是一种危险的方式 - 首先创建表，然后创建域，最后创建GUI。 我必须承认我不是ORM专家的专家，但我看到的生成的类看起来更像是数据对象而不是类。我会说你需要另一层来阻止所有逻辑在GUI中结束。