I am just starting a new ASP.NET project and using the MVP pattern. I did consider the MS MVC but it is not released yet and would be a big learning curve for some people on the team, so I opted for MVP now and possibly future projects MVC.
Anyway, it seems I will have a single Controller/Presenter class for every webform I have it the project. This is a lot of extra classes, essentially doubling the number of files in the web project. Is this how other people structure MVP or what are the alternatives?
This seems to be a common misconception -> "More files/classes == more complex"
The reason we chose to follow a UI separation pattern is to help separate concerns, make code easier and cheaper to change and maintain and (big, important and) we can unit test the complex parts and still keep the UI layer slim.
I'm going with the beta ASP MVC. The reason being, that while it is still only a beta (PDC very soon, that may have an impact on release and we've had 5 preview releases) it has a better framework to support this style than I could write in a reasonable time frame.
You could of course go with another framework, like castle monorail.
I think a lot of it depends but in most cases that is really the way it ends up going.
I personally use a n-tier architecture with data, business, presentation code. (Who knows what actual format I follow). I do get a lot more files than if I did everything in the aspx, but the code is much easier to manage.
To your question - I have seen many different takes on MVP and seen nothing that reduces the number of files, and I can't think of a way to reduce the number of files.
In my experience, I have reused view interfaces and even code behinds where the view structure is identical, but presenting different data. And you could also think of reusing the controllers where applicable.
I think it is worthwhile to note that having more files will be a natural consequence of moving to a more agile and test-drive development and developers will find it more and more natural as they go. (Just like some of us find it very natural having lots of methods inside a single file...)
Related
I am starting a new project and was going to use it learn asp.net mvc.
But time is short and I won't have time to meet the requirements, learn mvc and end up with a well designed system. So I need to start with asp.net v4 and EF.
What sort of things should I do to allow an easy transition to MVC later?
I'd say the most important thing is the separation between business logic and presentation logic.
If you have a lot of business logic embedded on the aspx or on the code behind pages the transition will be harder.
Another thing that could complicate the transition is how intensively you use asp net web controls. If you can use independent UI controls from server side language (not everywhere of course, but as much as possible), things will be easier to migrate.
If you don't have time to meet the requirements, then you didn't give yourself enough time. If you are limited by time it's presumably because you are working for someone else, and you're constrained by their timetable and/or budget, so you need to build on what you know.
You should never blindly implement on a framework you don't know. You need to build time for prototyping, learn on your own, or pull in talent that already knows. If you are using a new framework and there is uncertainty, you should have enough time that you can cut after a certain point and rebuild in a way you do know you can do it.
You should also build on the best framework for the job -- there is no one-size-fits-all solution for any problem. What framework you choose should be based on the user requirements, technical/business limitations, projected growth and life (maintenance needs), and your available resources. Choosing is based on your personal past experience, and prototyping. If you don't have the experience and don't have time to prototype in at least a couple frameworks, you are in a bad spot right from the start.
That all said, I personally think ending up with a "well designed" system in WebForms is INCREDIBLY difficult, especially compared to doing it within MVC, and that in the ASP.NET space MVC is a much better framework in almost all situations than WebForms. I am biased and will outright say I think Webforms is fundamentally flawed in its philosophy; most of the code works as small examples but falls apart and becomes unmaintable as you grow, and even the example code from MS suffers this issue. But you should not use some random person on the internet's opinion as the basis for your design choices. I am just pointing this out because I want to be clear that I am not endorsing specifically WebForms, I am endorsing "use what you know" -- whether you "know" it from previously using or take time to learn it.
I've seen some teams that start breaking into multiple projects from the beginning and others build behemoth single projects. The large project teams say that one massive project is easier to maintain than multiple smaller projects.
In general, how many files is too many?
The answer as George suggested it depends...but you may have large project with many areas which are new feature with asp.net mvc 2.0 . The time when you do want to break it another project is when you are trying to reuse that in another project. Since you do not want something coupled that it needs quite a few changes to work.
So, you need to analyze and understand the reusability of your projects.Ideally you would not want to have one big project with everything...you can divide into libraries..helpers..Models..etc..But again depends on how and what are you implementing..and sometimes a one large project also works.
There is probably no right or wrong answer here, but from experience, some teams know that certain components logically belong in a separate project, therefor they break it down initially.
Some teams might find that because a project is unmaintainable in it's current form, decide to break it down logically into more manageable parts.
As developers, we should always be breaking down problems into more manageable and consumable bits of work. The concept applies to solutions/projects that grow to a size that is just not favorable.
Short and simple answer.
If it becomes to big and messy, break it down.
We don't worry so much about 'files in project', rather we subdivide by 'projects contain logically related function'. Our base libraries are divided by functional area (UI, data access, etc), then the app components by function - reporting, contract maintenance/info, various odd & sundry table maintenance things, deal maintenance/info, rights maintenance/info, etc. (some of the terminology is domain-specific)
Given our translated-from-client/server app is fairly large, we decided that logically related separation would provide a simpler maintenance scheme.
If all your projects are in one solution, there's not really much of a difference (until you get beyond 10 or so projects). If you only plan on having one app, keep it in a single project but separate by folders if you feel that is easier.
We typically separate our project by tiers ... i.e. a web tier project, model/business logic tier, and data access or OR/M tier. It makes it easier for us to manage and conceptually think about the various apps. It also helps prevent us from mixing together concerns (i.e. you probably wouldn't want your model accessing the System.Mvc namespace, but if everything is in one project it's easier for a developer to slip such 'features' in).
I would like to know the best practice for a designing a simple CRUD application with some screens updating various tables (like admin pages to maintain static data for an application). the simplest way would be to drag a data grid/gridview, bind it to a dataset and use a data adapter for CRUD operations. but if this application needs to be scalable, lets say to add any extra UI/business logic in future, then is there any design pattern that can help with this? should I be using an object data source control and bind it to business objects instead? or are there any better ways of doing it? should I build a complete layered application or will that be overengineering for this requirement? any examples for UI design would also be helpful. thanks.
If you are looking for a really quick and easy approach, you can look at using Dynamic Data
http://www.asp.net/dynamicdata
on top of a Linq2SQL or EF4 backend - hardly any code needed at all.
+1 Oded. No offence RKP but you might be confusing "simple" with with "effective" or "value-for-money". I also think you might want to be more clear about exactly what it is you're after: example UI designs is quite a different issue from the logical architecture. Anyway - good on you for asking.
If this is a "tactical" solution: not expected to have a long life-span, or is a quick-and-dirty dev tool then how you build it might not be such a big issue. (also beware that short-term tactical apps can end-ed being long-term strategic ones - were working on an app now that the business see as a "temporrary" tool: they see it only being used for the next 5-10 years (!)).
If it's a tool the "business users" will use, then it's quite likely they'll expect changes overtime: depending on what the app is for a simple pass-through CRUD app might only cut the mustard for a short while.
So I guess this is where your admirable desire to look at best practice comes in.
Are you familiar with OO design? A lot of the principles behind good OO design also apply at the architectural level (SOLID, Common Reuse, Common Closure, Loose Coupling, Stable Dependancies and Stable Abstraction Principles).
lets say to add any extra UI/business
logic in future
So - this is where you need to consider up-front how you will seperate concerns and allow for growth: architecture doesn't mean you have to do a big upfront design, it just means you need to have an idea of how you'll grow the application as requirements grow..
To finish:
Have a good look at the different system quality attributes and work out which ones are particularly relevant to the system. prioritise them.
I get a lot of mileage out of Dependency Inversion (The D in SOLID) - abstract out things like data access early on.
For me the other really key "best practice" is to pay attention to SRP (the S in SOLID),
http://www.asp.net/mvc is my bet. It's easy to start with and get going... You won't be dissapointed. :) StackOverflow itself is built on top of it.
When I first heard about ASP.NET MVC, I was thinking that would mean applications with three parts: model, view, and controller.
Then I read NerdDinner and learned the ways of repositories and view-models. Next, I read this tutorial and soon became sold on the virtues of a service layer. Finally, I read the Fluent Validation documentation, and I'll be darned if I didn't end up writing a bunch of validators.
Tonight, I took a step back and thought about what had become of my project. It seems to have become the victim of the design pattern equivalent of "feature creep". Somehow I'd gone from Model-View-Controller to Model-Repository-Service-Validator-View-ViewModel-Controller. You want loosely coupled and DRY? We got your loosely coupled and DRY right here! But I'm wondering if this could be a case of too much of a good thing.
Am I right to be concerned? Or is this actually not as crazy as it sounds? On one hand, it seems crazy to have so many layers. On the other hand, every layer has a clearly defined purpose that makes sense to me. Have your MVC applications turned into MRSVVVMC apps too? If not, what do they look like? Where's that right balance?
If you have one form with three attributes, this is overkill.
But if you have a 'real' application, and the responsibilities of each layer are well defined, I'd consider it pretty reasonable.
It sounds to me like you found a pattern and went looking for a problem. You should find a problem, and use the appropriate tool from your toolbox... not all the tools. Unless this is an academic exercise of course.
We are currently designing a business application that has two primary requirements for it's UI:
1) run on the Desktop (WPF) for enterprise users to provide a rich user interface, interoperate with other applications, access the filesystem, work offline, work with special local hardware, etc.
2) run on ASP.NET/Ajax to provide several components of this application to customers (internet). Unfortunately Silverlight is not (yet) an option.
Even though we don't have to make the full application available on the web, some of these components are fairly complex and we would like to share as much UI code as possible with the WPF implementation.
What options do we have to reach this goal? Is there a pattern that works well with both technologies?
Update:
Thanks for the answers even though they don't include the one I was looking for! :)
I don't think UI generators are a good option. Like Eduardo pointed out you will probably end up with problems in both worlds. I will check out Sculpture though.
I've been thinking along these lines for a while now, and I've yet to come up with a great answer. That being said, here are some of my thoughts:
If you used some variation of the various MVP/MVC/MVVM UI methodologies and you were very disciplined in this approach (i.e. not mixing presentation stuff with behavior stuff), you'd probably be farther down the road.
You might consider investigating the various DSL toolkits that have cropped up, the idea being to create a simple "language" to describe your UI at a high level and generate a representation of that UI in WPF/ASPX.
Also, I ran across this recently. I have no idea how good it is. I'm planning to take a closer look when I get the chance.
Good luck!
The unfortunate truth is that Asp.net/ajax (the web in general for that matter) and WPF (and heck, let's throw WinForms in there for good measure) have very different User Interface models and what works well for one is not necessarily going to work well for another. That's not to say that you can't share logic between applications written for either technology, but, I'll make a stretch here, your UI logic is not going to be in that category.
I've been using a variation of MVVM for WPF and ASP.Net MVC most recently and I'd say they are very good fits for the technology at hand. However, while they are very similar, they have their differences and I'm not sure you could write an abstraction layer (in any decent amount of time) that could take advantage of the great features in both technologies.
Ultimately, I'd say that your best bet is to follow some SOA patterns and extract as much of your business and data access logic into common libraries as possible. Then, write separate user interfaces in WPF and Asp.net to take advantage of those common libraries. This is the approach that my company is taking at the moment, and it's working like a charm.
It may seem daunting to write your UI logic twice (once for asp.net and once for wpf), but I think it's worth it so that your code can fit the patterns and practices that best fit those technologies.
As an aside, even though Silverlight is not an option, have you considered XBAP?
If a former job we did something similar. As Daniel Pratt says, we describe our interfaces in XML and then a render will create the form, report or whatever we decided to create.
We have to provide a Javascript function to do some UI validations in the HTML render, and a call to a java function in the Swing render.
Beware that you may end with imperfect apps in both worlds.