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.
Software Solution Architectcommunity.rainbowportal.net