我正在评估我的下一个项目是否使用 NetTiers。
问题是：
我的架构中的每个表都有一个 AccountId 字段。对于向 DAL 发出的每个请求，我希望都要求传递 AccountId 并将其用作查询中的过滤器。
如果生成使用此参数的额外重载，则是可以接受的。
我怀疑此功能不是内置的，因此任何人都可以提供有关从哪里开始修改模板以添加它的建议吗？
I'm assesing using NetTiers for my next project.
The issue is:
Every table in my schema has a field AccountId. With every request to the DAL I want it to be a requirement that the AccountId is passed and used as a filter in the query.
It would be acceptable if an extra overload was generated that used this paramater.
I suspect this functionality is not built in so can anyone offer any advice about where to begin with the modification of the templates to add it?
发布评论
评论（1）
一旦您了解了 NetTiers 生成的类的迷宫，修改 NetTiers 模板并不困难，但它通常非常乏味且很容易出错。
我的第一个假设是，您生成的数据库要么只有几个表，要么是非规范化的 - 否则在每个表中都有一个 AccountId 列是没有意义的。如果是后者并且结构无法规范化，那么相信要让所有基于数据库外键（包括 DeepLoads）的内置导航属性与额外的AccountId一起使用，这将是一个相当大的改变筛选。
另外，您提到添加包含 AccountId 的重载将是一个可接受的解决方案。但是，这会将不需要 AccountId 参数的现有 NetTiers 重载留给任何 DAL 使用者...
无论如何，这里总结了您需要考虑修改的一些区域：
为了确保在不提供 AccountId 的情况下无法成功执行查询（例如，有很多方法可以通过
GetPaged @where子句规避默认 DAL），您可能必须在SQL层。这些模板位于/DataAccessLayer.*Client/文件夹中。假设您使用的是 sql server，生成 Sql 的文件 (这将导致相关文件发生更改，例如
/DataAccessLayer.SqlClient/SqlEntityProviderBase. generated.cst和/DataAccessLayer/EntityProviderBaseCore. generated.cst可能还有/DataAccessLayer/EntityProviderBaseCoreClass. generated.cst。这反过来会导致实体层发生变化 (
/Entities/），例如EntityBaseCore. generated.cst和EntityInstanceBase. generated.cst。我的一般建议是，虽然 NetTiers 和 CodeSmith 是几年前构建 DAL 的首选工具，但现在我不建议走这条路。随着 Microsoft 实体框架和开源 NHibernate 的发展，您实际上不再需要太深入地涉足数据访问管道层（即使仅在代码生成级别）。
Modifying the NetTiers templates is not difficult once you kind of know your way around the maze of classes it generates, but it is usually quite tedious and very error prone.
My first assumption is that the database you are generating off is either has only a few tables or is denormalised - otherwise it would not make sense to have an AccountId column in every table. If it is the later and the structure cannot be normalised, it believe it would be a fairly hefty change to get all the built it navigation properties based on database foreign keys (including DeepLoads) working with an extra AccountId filter.
Also, you mention that adding overloads containing AccountId would be an acceptable solution. However, this would leave the existing NetTiers overloads that do not require an AccountId parameter to any DAL consumers ...
Anyway, here's a summary of some of the areas you would need to look into modifying:
To make sure no queries can be successfully executed without providing an AccountId (there are plenty of ways to circumvent the default DAL via the
GetPaged @whereclause for instance), you will probably have to make changes at the SQL layer. These templates are located in the/DataAccessLayer.*Client/folders. Assuming you're using sql server, the file that generates the Sql (/DataAccessLayer.SqlClient/StoredProcedureProvider.cst) could be modified to ensure an @AccountId parameter is always passed.This will lead to changes in related files such as
/DataAccessLayer.SqlClient/SqlEntityProviderBase.generated.cstand/DataAccessLayer/EntityProviderBaseCore.generated.cstand probably/DataAccessLayer/EntityProviderBaseCoreClass.generated.cst.This in turn will lead to changes in entity layer (
/Entities/) such asEntityBaseCore.generated.cstandEntityInstanceBase.generated.cst.My general advice is that while NetTiers and CodeSmith were tools of choice for building DALs a few years ago, I couldn't recommend going down this path these days. With the evolution of the Microsoft's Entity Framework and open-source NHibernate, you shouldn't really need to dabble too deep into the data-access plumbing layer anymore (even if only at the code-generation level).