I'm taking another look at Model-View-Presenter (or Supervising Controller, whatever it's called nowadays) since we use WebForms exclusively at work and I think the separation of concerns can help.
My question is regarding the "View" interface - I understand that you create a view for each page, along with the presenter, and the ASPX page implement the IWhateverPageView interface so it can pass itself as the View the presenter will use. Where does that interface get created in regards to projects/DLLs? I know it's customary that the Presenters all have a MyProject.Presentation
class library they live in (and then you might have开发者_如何学编程 separate libraries for your Repositories/Services/Domain Objects/etc.). Does the IWhateverPageView
interface belong in the Presentation layer, perhaps in a child namespace (e.g. MyProject.Presentation.Views
)? Does it need its own library (e.g. MyProject.Views
)?
What is the common structuring for this?
I've done MVP a lot in WebForms, and I typically organized my project very simply to begin with.
MyProject.Web.UI
Contains the web site. Web pages, javascript, etc...
MyProject.Web
Contains all the Presenters, Views (interfaces) and logic needed to wire the UI to the business logic.
MyProject.Lib
Usually contains the domain logic, but if the project is simple enough, I shove this into the MyProject.Web assembly.
MyProject.Web.Tests, MyProject.Lib.Tests
You do have test projects right?
In the end, it really depends on what your needs are. There is no standard practice out there, so any convention you come up with should make sense to you and your team. If that means you have one, two, or twenty projects, then so be it.
I have one specific project that has the Models, Presenters, and View interfaces, so that the presenter can easily consume the view by the interface. It works very well for us. I don't think you need the contract in a separate layer; the idea is that the view interface represents a contract so that it can work with the presenter...
精彩评论