align-toparrow-leftarrow-rightbackbellblockcalendarcamerachatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-crosscrosseditfacebookglobegoogleimagesinstagramlocation-pinmagnifying-glassmailmoremuplabelShape 3 + Rectangle 1outlookpersonplusImported LayersImported LayersImported Layersshieldstartwitteryahoo

Re: [dotnet-120] Programming to an Interface (or not?)

From: Eric R
Sent on: Tuesday, October 6, 2009 1:53 PM
Noah, ?I have found that using 1 interface per group of like but abstracted objects works a little better. ?I also usually just make the domain models just entities and thats it. ?I dont add any logic only an interface tying to Properties or shared methods not actual business logic. ?I then make Business Logic act on the BO and return it to the front end. ?You make far less business logic then entity so it seems better to make 1 interface for all ents and then an interface per your business logic. ?FAR easier to control.

In a perfect world, we would just make ents on the fly ( like some systems are trying to do including the "entity framework"). ?I like to use the above system with IBATIS or NHIB. ?With Ibatis, you only need to full an entity and pass it to a general method ( best part about it). ?

User does action

page calls business logic

business logic calls gateway assembly

gateway assembly calls SQL or Web Service or both

business logic fills plain vanilla business object

return to the page

return to the user

This way you have complete separation + you have your business logic in 10 or less class files with as many entities as you want. ?You can then group functions that are similar and reduce code maintaining only 5 interfaces.?

Currently I have 400 Business Entities and only 5 Business logic classes. ?I can always abstract this to build the entity on the fly and my logic classes can remain the same.

I have found that you should code to an interface especially when making the application from the UI to the DB and not the other way around. ?If you make the UI first, the architecture will flow. ?As for code, you never need to go above and beyond and interface yourself to death. ?Interfaces are suppose to be for like minded objects that will behave differently on implementation. ?If you make an interface for every object, chances are you will not use it for that intended purpose.

Eric Ramseur
Software Solution Architect |

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy