Question

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?

Answer 1

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 @where clause 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.cst and /DataAccessLayer/EntityProviderBaseCore.generated.cst and probably /DataAccessLayer/EntityProviderBaseCoreClass.generated.cst.

• This in turn will lead to changes in entity layer (/Entities/) such as EntityBaseCore.generated.cst and EntityInstanceBase.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).