Dataservice design question

K

Kevin C

I have 3 assemblies:
A. Business Entities
B. Business Logic
C. Data Access

In order to not have circular reference back to my business entities library
I was creating an API that accepted each data field instead of an object.
How is this percieved in the developer community? Referencing back to the
business entity assembly seems like a dependency that does really need to be
there.

Example:
public int InsertSomething( int someKey, int someNum, string comment, int
shipMethodCd, int shipLocNum, int reasonCd, int cartonCount, string
trackerNum, int recvLocNum, DateTime modifiedDt, string modifiedUser) {
}
 
N

Nicholas Paldino [.NET/C# MVP]

Kevin,

I personally don't think that there is anything wrong with that. If
anything, I like it more than passing an object, because a business object
usually has to be rehydrated from the data source (and you might not always
have that on hand).

Your logic isn't tied to whether or not there is data in the database.
For example, if you had a function that could calculate interest payments,
you should have a function that accepts the interest schedule, the amount to
calculate interest on, and a from and a to date. Now, you might normally
have all of this in tables in a database, and you might be tempted to do
this:

CalculateInterest(int scheduleId, DateTime from, DateTime to)

However, this is a bad idea, because now you have to depend on a
schedule existing in the table, when the logic shouldn't have anything to do
with that. Rather, the above function should be a convenience function
which ultimately calls a function which will return the value, and not be
tied to the data.

Hope this helps.
 
S

SP

Kevin C said:
I have 3 assemblies:
A. Business Entities
B. Business Logic
C. Data Access

In order to not have circular reference back to my business entities
library
I was creating an API that accepted each data field instead of an object.
How is this percieved in the developer community? Referencing back to the
business entity assembly seems like a dependency that does really need to
be
there.

Example:
public int InsertSomething( int someKey, int someNum, string comment, int
shipMethodCd, int shipLocNum, int reasonCd, int cartonCount, string
trackerNum, int recvLocNum, DateTime modifiedDt, string modifiedUser) {
}
Click to expand...
You can also consider having a Business Interfaces assembly so that the Data
Access assembly does not require a reference to the Business Entities
assembly.

SP
 
Top