DAL 中数据库对象的分离级别
在这里寻找一些一般性建议。
选项 1。 最好让所有主要数据库对象（例如联系人、用户、客户等）在 DAL 中拥有其通用类，并为依赖于主要对象（ContactAddress、UserEmail 等）的数据库对象嵌套类...这些将有多个值，因此它们包含在单独的表中）
或
选项 2。 对于像 ContactAddress 等这样的东西拥有完全独立的 DAL 类并将这些元素组合在业务层中会更好吗？
如果我在这里没有意义，请告诉我。
Looking for some general advice here.
Option 1.
Would it be best to have all of the main database objects (say Contact, User, Customer, etc. have their general classes in DAL with nested classes for db objects that depend on the main objects (ContactAddress, UserEmail, etc... these would have multiple values so they are contained in separate tables).
OR
Option 2.
Would it be better to have completely separate DAL classes for things like ContactAddress, etc. and combine these elements in a business layer?
Let me know if I'm not making sense here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我通常在业务逻辑层中定义对象，并在 DAL 对象和业务对象之间进行一些转换。我的 DAL 对象通常由某些 ORM 框架（例如 EF 或 LinqToSQL）自动生成。原因是我的业务逻辑层对象不是POCO的，但也包含业务逻辑，而DAL对象是纯粹的poco（尽管它们可能用一些ORM逻辑装饰）。
I usually define my objects in the business logic layer and do some translation between DAL objects and business objects. My DAL objects are usually autogenerated by some ORM framework (such as EF or LinqToSQL). The reason for this is that my business logic layer objects are not POCO's but also contains business logic, whereas the DAL objects are purely poco (although they may be decorated with some ORM logic).
如果将所有公共类放在命名空间级别（而不是作为内部类），通常有助于发现。
您引用的两个示例可以概括为无害：
ContactAddress变为AddressUserEmail变为Email这样，如果您愿意，您可以稍后重复使用它们。
It usually aids in discovery if you put all public classes at the namespace level (instead of as inner classes).
The two examples you cited, could be generalized with no harm:
ContactAddressbecomesAddressUserEmailbecomesEmailThis way, you can reuse them later if you wish.