Last post Jul 27, 2011 06:27 PM by AaronLShumaker
Jul 14, 2011 02:46 AM|AaronLShumaker|LINK
This is a 2 part question. I did first search the forum and read several similar DD/MVC topics but many addresed the "HOW" of combining MVC/DD and were very old topics as well. I am interested in the current state of DD targeting MVC(see part 1) and also
what approach provides a good combination of ease/rapid development without boxing me in where I can't do out-of-the-ordinary things later as-needed. Also wqould like to understand where the overlap, so that I understand whether routing in DD is the same
thing in MVC, and whether View/Actions are the same technology in both, or just similar things using totally different things that just accomplish a similar goal.
1) I've seen the links to sample experiments for integrating MVC and DD(one is broken, other is here http://aspnet.codeplex.com/releases/view/18803), and also some examples of how to make both live together in the same project, but in all of those discussions(2008/2009
timeframe) some Microsoft chap often chimes in that they are working on targeting MVC with DD. So did that ever come to fruition? Or is that still something tentative/TBD that never got further than those experiments?
2) Being new to both DD and MVC, alot seems very similar and I wondered what is really the same and what just appears to be the same. As an analogy, when initially learning LINQ/EF I was tripped up by the fact that there are many different flavors and examples
of LINQ usage which do not work with EF (Linq to SQL, LinqDataSource.Select, etc.). I still struggle when trying to do more advanced things with Linq because I never know what will and will not work in my particular scenario.
So I would like to understand where DD and MVC share similar concepts/technologies, and where they are really different. They both seem to have templates for different actions(DD crosscutting insert/delete/etc. for all entities with options to customize
for individual entities, MVC generates these for all entities and you can customize each), and seem to be driven by the structure of the underlying data model(i.e. what properties are exposed by POCOs/Entities/etc.), and also both use routing in some way.
So with both technologies you can easily scaffold out a data entry/browsing application and have capabilities to customize both. In my experience, such very dynamic technologies have a tendancy to paint you into a corner where you have increasing difficult
to wrangle the technology into doing what you need as users begin to add requirements that involve little "special cases" where they want something to behave differently. It is really great in the beginning, but those finely detailed tweaks can really bite
you in the butt.
So I think what I am wondering the most is, which technology or approach of using both will give me the most freedom to tweak/bend the rules when my requirements call for it? I don't really have the time to invest in learning the details of both technologies
at one time so I can't really evaluate how they compare when it comes to customizing behavior, and would just like some insight from some people who have used both.
3) I lied there are 3 parts. In seeing that DD has a similar actions layout to MVC, I wondered if DD can use the Razor engine?
Sorry if my thoughts seem a bit rambly/chaotic.
I have to say that DD seems awesome in that I can sit down in design meetings and modify the Entity model on-the-fly and be able to present business analysts with a layout so that the affect of the data model is clear in terms of example data entry, and
I can even have business analysts enter example data for the purpose of testing the data model/data types/data lengths/relationships and also the example data can then be easily added to data dictionaries documenting the system. Also, as mentioned often,
I see DD as a great backend tool for when we want to correct some data quality issue in a way that the regular frontend wouldn't typically allow, or we simply didn't want to invest development resources to adding the capability to the frontend because the
need was so rare that the DD backend+data steward could take care of the issues.
But just from my reading, without having used either much, it seems DD has the same potential/capabilities, if not implemented differently, as MVC in terms of customization. Yet MVC seems to get the bulk of the attention on the web, and also following some
MS blogs, gets more updates/new features. I was just reading today about MVC support for spatial data types and enums in the new CTP. I won't ask the "Is DD dead?" question because I've seen that answered many times already. What criteria should I use to
determine which approach to take? On the surface they seem to support the same scenarios/desires in only slightly different ways.
I am single handedly building a data model and data entry application that overtime will integrate more and more data elements and business rules. There is already a huge lists of data elements. So I am trying to quickly ascertain which path will be the
most efficient without causing me headaches later down the line. It will initially just be a blunt force tool to let them move into a new era of storing all of their data in a queryable, centralize database(which feeds into a DW, which I also single handedly
built to integrate some legacy data). I want to know how much of a headache each approach will be when I later go back and make some data entry screens more efficient/helpful/enforce business rules/support business process workflow/etc. All the little fine
tweaks and details that will eventually make the system more than just a bunch of simple data entry screens, and actually support/compliment the business processes.
Jul 15, 2011 05:26 AM|sjnaughton|LINK
The simple reply is that DD sites on top of ASP.Net WebForms and MVC is a seperate framework build directly on top of ASP.Net and avoids web forms. Where the share is in the area of attributes on the data model to control how they behave.
Jul 17, 2011 03:18 PM|olegsych|LINK
I am sorry in advance for a brief response. You have obviously but a lot of
thought in your question, but I don't know if I can write an essay here.
I agree with what Stephen said - Dynamic Data and MVC share some concepts,
specifically field templates in Dynamic Data are similar to editors in MVC.
Your preference can be based on the choice of platform itself (WebForms vs.
MVC). There is, however, a bigger difference between the two. Whereas the MVC
framework is geared toward design-time generation of the UI code (scaffolding),
Dynamic Data is geared toward run-time code generation and the tradeoffs
between them are consistent with these different approaches. MVC is easier to
customize, because you can freely modify the views after they are generated,
however the downside is that in a large application, the number of generated
views can get quite large. Dynamic Data, on the other hand, significantly reduces
the amount of the code you need to have in your application at the cost of
increase in complexity (metadata, template interactions, etc.). If your
application has a small number of entities that need unique, polished UI, MVC
may be a better choice. On the other hand, if you have a large number of
entities that need more generic UI, Dynamic Data will help you to reduce the
overall amount of code you have to write and maintain.
Hope this helps
Jul 17, 2011 06:39 PM|Topolov|LINK
I have asked this question and I have seen some others asking almost the same question: what is the future od Dynamic Data?
I have also seen some answers: It'll continue being suported, which doesn't really says much because Visual FoxPro was also supported for a a long time, I think it came until release 9, but it was clearly known
that it was already deprecated. It was bruied. No future for it
Nevertheless I think it was necessary to support it because of its huge demand all over the world, for decades
So, if you a programmer asks something about a product then you'll expect to have an honest answer from Microsoft people, no offense but just the simple truth
So if Dynamc Data is going to disappear, or it was released by accident or was released hopping that'll be used as a testing scenario utility only then it will be enough if you let us know guys such thing, clearly
The person who wrote this post says that there are many similarities and he might be right so it'll be good if you can give a real answer about the future of Dynamic Data
What'll be the purpose of spending so much time in a leraning curve of something you should have never learned extensivelly as Dynamic Data if it not really good enough for developing a seious application ? If MVC
is the way to go then say it and we'll go there
But please don't lie, we deserve better
If I'm wrong I apologize but if I'm not the you should correct all of Dynamci Data deficiencies once and for all
It seems unfair that we only expect real and deep answers from a single contributor who seems to be the only person in the world interested in Dynamic Data study, improvement and help to others interested in such
MY GRATITUDE ON ThIS TO STEVE NAUGHTON
P.S.: I must add that when you develop an application the first thing to know ate the "User Requirements" isn't t? So, if Dynamic Data is an application: shouldn't our request be listened, solved and implemented
in a product which is deliverted as part of the Visual Studio Famework?
If I were to judge based on all th questions that you can see in this forum then for sure you'll have along list of "Use Cases" to solve in the Dynamic Data field
Jul 18, 2011 08:14 AM|Topolov|LINK
BTW I hope you read my comments as an assertive opinion not as a belligerently position from my side
I wish I hadn't asked
Jul 27, 2011 06:27 PM|AaronLShumaker|LINK
olegsych, those were excellent points and that is exactly what I was looking for, thanks!