tag:blogger.com,1999:blog-11393788.comments2024-03-09T00:32:10.709-08:00Vikas's Technical BlogVikashttp://www.blogger.com/profile/11330187546301885403noreply@blogger.comBlogger35125tag:blogger.com,1999:blog-11393788.post-57165049362124505072024-03-06T06:52:02.082-08:002024-03-06T06:52:02.082-08:00Microsoft's venture into quantum computing sig...Microsoft's venture into quantum computing signifies a bold leap towards the future of technology. Part 3 of the series delves deeper into their innovative strides in this groundbreaking field. Quantum computing holds the potential to revolutionize industries, from healthcare to finance, by solving complex problems at unprecedented speeds.mobilezmarkethttps://www.mobilezmarket.com/noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-6053302057337635452024-03-06T06:23:27.998-08:002024-03-06T06:23:27.998-08:00Microsoft's exploration of future technology, ...Microsoft's exploration of future technology, particularly in the realm of artificial intelligence, is both fascinating and promising. As AI continues to advance, Microsoft's efforts in this space are crucial for shaping the future of technology and its applications. mobilezmarketnoreply@blogger.comtag:blogger.com,1999:blog-11393788.post-88183102775403265272023-08-16T03:20:12.076-07:002023-08-16T03:20:12.076-07:00If you are searching for a web design & develo...<br />If you are searching for a web design & development company in Australia, you are at the right place.<br />Maacstudios is the best <a href="https://maacstudios.com.au/web-designing-parramatta/" rel="nofollow"> web design Parramatta </a> company Australia. Because a website is the most <br />important part of a company, it needs to be interesting and eye-catching to attract potential clients.fscna-mianhttps://www.blogger.com/profile/18118235353551266628noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-31176412550294111142023-07-12T23:09:16.510-07:002023-07-12T23:09:16.510-07:00Great Information! Read my latest article How Digi...Great Information! Read my latest article How Digitalization <a href="https://fretron.com/how-digitalization-reduces-tat-in-plants/" rel="nofollow">Reduces Turnaround Time</a> (TAT) In PlantsHimanshu Sainihttps://www.blogger.com/profile/05994165475922926227noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1156724257277590292006-08-27T17:17:00.000-07:002006-08-27T17:17:00.000-07:00Hi Survic,This is one of best articulated posts th...Hi Survic,<BR/>This is one of best articulated posts that I have come across on this topic.<BR/>But you can ignore MVC only if you are streaming HTML only to Browser.<BR/>if you are streaming HTML to other devices (e.g,. Mobile,Excel,MsWord), you have to use some form of MVC.<BR/>As you said code-behind is tied to view, it is not a true controller. So from code-behind, you have to initiate a true controller and keep your code(creating and manipulating Model) there.Vikashttps://www.blogger.com/profile/11330187546301885403noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1156653245083813992006-08-26T21:34:00.000-07:002006-08-26T21:34:00.000-07:00You have a way to find things to discuss! This MVC...You have a way to find things to discuss! <BR/><BR/>This MVC thing prompts me to think about why MVC is so confusing, there are 5 elements: <BR/><BR/>http://survic.blogspot.com/2006/08/why-mvc-is-so-confusing.htmlsurvichttps://www.blogger.com/profile/05621218802357307115noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1155935844406668432006-08-18T14:17:00.000-07:002006-08-18T14:17:00.000-07:00Arun,You always go for easy target. :)Arun,<BR/>You always go for easy target. :)Vikashttps://www.blogger.com/profile/11330187546301885403noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1155859402941582142006-08-17T17:03:00.000-07:002006-08-17T17:03:00.000-07:00May be Microsoft thinks that not many English spea...May be Microsoft thinks that not many English speaking people would require it. It caused me grief for four days. It disrupted my re-reading of Expert C# Business objects. You would be surprised that I got the feeling that lot of Charing Venders were being asked this question for first time. So much for Globalization. :)Vikashttps://www.blogger.com/profile/11330187546301885403noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1155778485553163122006-08-16T18:34:00.000-07:002006-08-16T18:34:00.000-07:00Tricky. I wonder why it is not installed by defaul...Tricky. I wonder why it is not installed by default, we are in the Internet age ... Do we really care the disk space? Or, it affects memory size, or, it interferes other things?survichttps://www.blogger.com/profile/05621218802357307115noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1155607901157104762006-08-14T19:11:00.000-07:002006-08-14T19:11:00.000-07:00Survic wrote"I guess we can safely say that we all...Survic wrote<BR/>"I guess we can safely say that we all agree that SOA is adding (not changing, simply adding) another half a layer (not even a whole layer) that is similar to “workflow” layer, and is more document-oriented and message-oriented communication. <BR/>"<BR/><BR/>One thing that I think that driving this layer without requirements is very difficult. With out requirement, one is simply shooting in dark and will cause him despair. But if you have requirements, adding this layer is very easy.Vikashttps://www.blogger.com/profile/11330187546301885403noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1155148873489941442006-08-09T11:41:00.000-07:002006-08-09T11:41:00.000-07:00I agree with you now, 100% :-)The database storage...I agree with you now, 100% :-)<BR/><BR/>The database storage details -- you are right: I have to hide them if they are too messy. If I insist on the “data driven” stuff, then, I have to cheat, and persuade myself with the differences among conceptual/logical/physical data models.<BR/> <BR/>However, as you may guess, I do not like those demarcations; because the advantage of database is that the turn-around time between schema design and real data (the “manual Fit”) is within minutes. <BR/><BR/>More about “manual Fit”: I remember that originally (in the age of DB2 and Oracle) relational databases were build under the assumption that users are supposed to use sql/plus directly. That is the spirit of “manual Fit”! <BR/><BR/>Admittedly, it turned out that it was an invalid assumption, however, business analysts, or, developers who wear analyst hats should do such “manual Fit”. <BR/><BR/>Anyway, I found “manual Fit” is a good concept. I am going to use it everywhere. On the other hand, it adds some non-pure-OO elements to Fit though ;-)survichttps://www.blogger.com/profile/05621218802357307115noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1155092426869938982006-08-08T20:00:00.000-07:002006-08-08T20:00:00.000-07:00Survic wrote “So, if it is a new database, we desi...<B>Survic wrote <BR/>“So, if it is a new database, we design it ourselves; if it is a legacy one, then, we need the data within it. Either way or both ways, we need to deal with database early on.”</B><BR/><BR/>Let us keep the context right.<BR/>So, if it is a new database, we help DBA to design ; if it is a legacy one, then we need the data within it. Either way or both ways, we need to deal with DBAs early on. DBAs will have their own deadlines and their own priorities.<BR/><BR/><BR/>Now I will switch to your context. When you are designing the database , it is very important to make sure that you have all the data that user is asking for reporting. One can use Screen Mockups, relevant E/R diagram(60% to 90%), Process logic in form of (Class diagrams, Sequence Diagram, activity flow charts) to communicate with users. That is perfect. My contention was that while it is okay, do the database design simultaneously but hide it from user by exposing them to entity domain model. A model which uses vocabulary with which users are more familiar but hides the complex storage and retrieval details from users will be more useful. But if you think that it will waste of time. I again agree with you 100 percent.<BR/><BR/><B>Survic wrote<BR/>I am waiting for your ideas on a domain model without being “anemic". </B><BR/>I did write how I see Domain Model as one level abstraction over database hiding the data storage and retrieval.<BR/>Domain model will be anemic from 60% to 90%. Let me tell you about my experience of Domain Driven Design. I was working on a project six years back with DBA in charge of Database Design and we were pulling lot of data from legacy system. So, database diagram was a secret till the end of design phase. We, developers did give lot of inputs about data requirement and how we think that certain aspects of data storage should be like. Besides creating the Screen Shots, data flow diagrams, I also prepared a Domain Model by finding all the actors and their characteristics/behavior. Finally I optimized my domain model by decomposing the entities that have one-to-one relationship in single entities.<BR/>When I saw the database E/R diagrams at the end of design phase, it exactly matched my domain model. I felt like a fool but it was not in my hand. My regret is that I didn’t scope the process classes in design phase. I ended up writing a thin client with all process/workflow/co-ordination logic in the UI Layer. I corrected this during refactoring in next phase of development. We were following waterfall methodology.<BR/>I think that it is criminal not to use E/R diagram when it Is handy, to derive the entity classes. Somewhere you have to stop being self-righteous and deliver solutions to users when pay you your monthly check. <BR/><BR/><B><BR/>Survic wrote:<BR/>I have seen a lot of derogative comments about it, but have seen nothing that can solve the problem<BR/></B><BR/>You should sugar-coat it to Object Purists by saying “Let us use Database diagram as a starting point for our Domain Driven Design.” And you can stretch the starting point as much as you likeVikashttps://www.blogger.com/profile/11330187546301885403noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1155084674420677192006-08-08T17:51:00.000-07:002006-08-08T17:51:00.000-07:00Continued to ...http://vikasnetdev.blogspot.com/20...Continued to ...<BR/><BR/><A HREF="http://vikasnetdev.blogspot.com/2006/08/domain-driven-design-based-on-entity.html" REL="nofollow"><BR/>http://vikasnetdev.blogspot.com/2006/08/domain-driven-design-based-on-entity.html</A>Vikashttps://www.blogger.com/profile/11330187546301885403noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1154578060637831522006-08-02T21:07:00.000-07:002006-08-02T21:07:00.000-07:00I guess it is a book for re-thinking and reviewing...I guess it is a book for re-thinking and reviewing, which can be very useful.survichttps://www.blogger.com/profile/05621218802357307115noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1154566148434887212006-08-02T17:49:00.000-07:002006-08-02T17:49:00.000-07:00Now I understand why O/R mapping is such a big sub...Now I understand why O/R mapping is such a big subject in J2EE environment not in .Net environment.Vikashttps://www.blogger.com/profile/11330187546301885403noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1154565780956688992006-08-02T17:43:00.000-07:002006-08-02T17:43:00.000-07:00Survic wrote"However, I do find a source: http://w...Survic wrote<BR/>"However, I do find a source: http://www.ambysoft.com/books/theObjectPrimer.html. I did not dig into it too much; and from what I saw, it did not go to the extremes as I did, but it shares the same points: database should be in the domain modeling picture, and developers should use data modeling as one important source of information. "<BR/><BR/>I read the Object Primer and found the following tit-bits.<BR/><B>Conceptual Modeling or Domain Modeling<BR/>Various types of Model you might want to use for conceptual domain modeling<BR/></B><BR/><BR/>1. Robustness Diagrams;<BR/>2. Object Role Model(ORM) diagrams;<BR/>3. Class responsibility collaborator(CRC) models;<BR/>4. UML class diagram<BR/>5. Logical data models(LDMs);<BR/>6. Analysis patterns;<BR/>7. UML object diagrams.<BR/><BR/><BR/>The fit between object technology and RDB technology is not perfect. In the early 1990s, the difference between the two approaches was labeled the object/relational impedance mismatch, also referred to as the <B><BR/>O/R impedance mismatch</B><BR/> or simply the impedance mismatch; terms still in common use today. Why does a technological impedance mismatch exist? The object-oriented paradigm is based on proven software engineering principles. The relational paradigm however is based on proven mathematical principles. Because the underlying paradigms are different, the two technologies do not work together seamlessly.<BR/><BR/>There is also a cultural impedance mismatch between developers in the object community and data professionals in the data community. Object developers have been taking an evolutionary approach to developments for years and now moving towards agile development methods such as extreme programming. Unfortunately many within the data community look upon evolutionary development as a questionable approach, and agile approaches are just now being considered.<BR/><BR/>When it gets right down to it the real issue is that data professionals view the world as data to be manipulated, whereas object developers view it as objects to be combined to perform behavior.<BR/><BR/>Data are important.<BR/><BR/>Data are one of many issues. Although data are important , so is telecommunication, user interface development, working with stakeholders, buinsess component architectures, frameworks, understanding the business domain, and so on.It is quite common for data professionals to overestimate the importance of data, which is unfortunate.<BR/><BR/>You need to look at the enterprise pictures. Luckily data professionals are often very good at considering enterprise –level issues-yet another reason developers should work with them closely.<BR/><B><BR/>Everyone needs to work together.<BR/><BR/>Common legacy data challenges<BR/>I am listing some from book<BR/></B><BR/>1. A single data field is used for several purposes.<BR/>2. The purpose of a data field is determined by the values of one or more columns.<BR/>3. Inconsistent values are being stored in a single data field<BR/>4.There is inconsistent/incorrect data formatting with in a column.<BR/>5.Important entities, attributes and relationships are hidden and floating in text fields.<BR/>Data values can stray from their field descriptions and business rules.<BR/>6. One attribute is stored in several fields.<BR/><BR/><B>My Comments</B><BR/>Context: Big projects. DBA doing the database design<BR/>it is more important to nail down requirements in Design rather than figuring out Data storage requirements. Because of O/R impedance, one may put extra effort into data storage effort rather than in discovering the problem domain.It is okay that data storage requirement activity to span over construction but not requirement gathering. If requirement gathering activity spills into construction, it can be very expensive<BR/><BR/>Tomorrow, I am going to post Rocky's comment on O/R impedance.Vikashttps://www.blogger.com/profile/11330187546301885403noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1154471699898704982006-08-01T15:34:00.000-07:002006-08-01T15:34:00.000-07:00survic wrote "I felt I need more definitive source...<I>survic wrote "I felt I need more definitive source to support my point of view. I did some research; frankly, I have to admit that I am not on the mainstream" <BR/></I><BR/><BR/>Because we solve real problems for paychecks not make living out of writing books. <BR/>Jokes apart, our focus has been more on tactical projects (1-6 months) where Data Driven Design works fine. Rocky, Martin and Eric focus is more on strategic projects which span over multiple years and have layers of bureaucracy.Vikashttps://www.blogger.com/profile/11330187546301885403noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1154470443462776912006-08-01T15:14:00.000-07:002006-08-01T15:14:00.000-07:00Thanks for great input.Here are answersvikasnetdev...Thanks for great input.<BR/><BR/>Here are answers<BR/><A HREF="<br/>vikasnetdev.blogspot.com/2006/07/soa-friendly-architecture-version-of_25.html" REL="nofollow">SOA Friendly Architecture version of Jeffrey Palermo's Architecture -- Part 2 -- Architecture </A>Vikashttps://www.blogger.com/profile/11330187546301885403noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1154469572030875542006-08-01T14:59:00.000-07:002006-08-01T14:59:00.000-07:00I guess we can safely say that we all agree that S...<I>I guess we can safely say that we all agree that SOA is adding (not changing, simply adding) another half a layer (not even a whole layer) that is similar to “workflow” layer, and is more document-oriented and message-oriented communication. <BR/></I><BR/>Cannot disagree with this comment.Vikashttps://www.blogger.com/profile/11330187546301885403noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1154298413914602812006-07-30T15:26:00.000-07:002006-07-30T15:26:00.000-07:00Just come back from a trip... I agree with your po...Just come back from a trip... <BR/><BR/>I agree with your post; however, I also see the subtle and interesting differences.<BR/><BR/>I noticed you mentioned three things at the end of your post (a) “It is more Document Style of communication”; (b) “SOA is more like workflow”; (c) “However I think that if you have good Middle Layer, adding a true service layer should be a small issue”.<BR/><BR/>My whole arguments are based on those three points. If you build entity objects (including containment – i.e. “aggregated entity objects, and also including “value objects”) and some necessary DTOs (data transfer objects), then, they can be changed to XML easily. Then, when it is necessary, we can simply select some façade and workflow objects as the services. Perhaps sometimes we need to make it even more coarse-grained; but we do that all the time within façade and workflow layers anyway– that is the very nature of façade and workflow layers: constantly changing to reflect business workflow/use-case changes. <BR/><BR/>Put it in another way: in classic asp or servlet or cgi (note that asp.net hides more, so, I would not use it here as an explanation tool, but I will use it later, see below), the response is html based; web service is xml based. That is the only real difference. You may say, “we need more standards and therefore specs in web services”, true, but that is what xml implies. <BR/><BR/>However, we all know asp.net and classic asp are both in the “application architecture”. Asp.net makes things more like winform by using postback. Ajax/Atlas makes it even more so. <BR/><BR/>I guess we can safely say that we all agree that SOA is adding (not changing, simply adding) another half a layer (not even a whole layer) that is similar to “workflow” layer, and is more document-oriented and message-oriented communication. <BR/> <BR/>As for the differences, they really depend on the context. I can easily imagine that I can argue a SOA is very different from an Application Architecture when I am focusing designing the half layer of the service, when I need to zoom in, and amplify details. <BR/><BR/>I guess the key reasons that I want to point out that there are not big differences are that (a) SOA’s new stuff is an addition; (b) the crucial business logic (“domain logic”) is in the business layer. As a result, for an application developer, SOA is the plumbing, or, even just a “distraction”. (My impression is that Rocky also holds the same attitude, but via a different route though – very interesting)survichttps://www.blogger.com/profile/05621218802357307115noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1153709795825741362006-07-23T19:56:00.000-07:002006-07-23T19:56:00.000-07:00I found a nice blog.I just read Domain Driven Desi...I found a nice blog.<BR/>I just read Domain Driven Design section of blog<BR/><BR/>http://steve.emxsoftware.com/Domain+Driven+Design/<BR/><BR/>I was really excited to read domain driven design and went through same emotions while reading the book. My criticism of book that most of the patterns book discusses I am aware of . May be I should have read books few years back.Vikashttps://www.blogger.com/profile/11330187546301885403noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1153694610635791412006-07-23T15:43:00.000-07:002006-07-23T15:43:00.000-07:00Vikas’s Thinking StartsSince I am locked in mortal...Vikas’s Thinking Starts<BR/>Since I am locked in mortal combat with Survic over Domain Modeling vs Data Modeling. Here is my strategy, concede tactical defeat to Survic. Fight Survic on my favorable grounds and make sure Survic cannot use his best weapons ‘Small projcts’ in his arsenal and win the strategic battle. Here comes my offense <BR/>Vikas’s Thinking Ends<BR/><BR/><BR/>Hi Survic,<BR/><BR/>I agree with you that Data Modeling wins hands down for small project and when programmer is also designing database.<BR/><BR/>What would you suggest in a environment when you are not in charge of database design.but DBA.? Do you agree that kind of environment exist? I had been in those environments. Would you wait for DBA to finish Database design and get caught with out a domain model in Design Phase? Mock screen are simply illusions of design and implementation which has to backed by Domain or Data Model. What is approach do you suggest in such situation? Taking DBA out of equation is not any option and project duration is 10 months<BR/><BR/>I have added more thoughts to my postsVikashttps://www.blogger.com/profile/11330187546301885403noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1153694263995703522006-07-23T15:37:00.001-07:002006-07-23T15:37:00.001-07:00added two more sections to th post1. People unders...added two more sections to th post<BR/><BR/>1. People understand Mock Screens More <BR/><BR/><BR/>2. People don’t understand Objects but User Interface<BR/><BR/><BR/>Reference:<BR/>Domain Driven Design – by Eric EvansVikashttps://www.blogger.com/profile/11330187546301885403noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1153552257079669302006-07-22T00:10:00.000-07:002006-07-22T00:10:00.000-07:00I have some comment here:http://survic.blogspot.co...I have some comment here:<BR/><BR/>http://survic.blogspot.com/2006/07/business-object-domain-object-and.html<BR/><BR/>I know I am picky on this one; but I got bitten by this many times, in both java world and .net world. Let's use MS's terminology.survichttps://www.blogger.com/profile/05621218802357307115noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1153191411441705422006-07-17T19:56:00.000-07:002006-07-17T19:56:00.000-07:00Yes, we are getting close. Domain Driven Design is...Yes, we are getting close. Domain Driven Design is going to get two new practitioners or none.<BR/><BR/><B>Context</B><BR/>Let get the context right.<BR/><BR/>Data Driven Design wins hands down for small project.<BR/><BR/>I will be lying to you if I say that I don’t use Data Driven design for most of projects the way you described. I also thought that it is pragmatic and cost effective approach. Create the Mock ups, design the database and derive the entity classes in free.. Then design the controllers and process classes and get the job done. I also held the belief that Domain Driven Design and/or CRC Analysis is for crazy guys with beards who write books. <BR/>When reading Fit, I realized that Domain Driven Design may be better approach when I thought the system from business user perspective.<BR/><BR/>Before going further, I am still exploring the Domain Driven Design. I have not uet joined the other side. I have just read 20% of book. Feel free to correct me if you think that I am wrong. I am excited about Domain Driven Design otherwise I would not have spent 50$ and wasted my time to read it. After finishing it, I am going to rate this book either 1 out of 5 or 5 out of 5. This is one of few books in which I am going read case studies. Generally I skip them and use in real practice. Be paitent with me. :)<BR/><BR/>Important thing is to get Entity, Process and/or Controller classes right. <BR/><BR/><B>Question: What if you are not designing the database but the powerful DBA ?</B><BR/>You don’t get the opportunity to design the database, though you may provide the inputs to DBA . DBAs design the table and they have their own way of designing for consistency and extensibility. In real enterprise environment, you have to face O/R mapping waterloo. It may make more sense to Invoice Entity object to have Paid attribute as Boolean(ture./false) but in database , you may be storing as 1, 0 because it was decided by DBA to standardize in database or database does not offer Boolean data type.<BR/><BR/><B><BR/>Data Driven Design could ignore Controller and/or process classes<BR/></B><BR/>90% of people who user Data Driven Design, ignore controller or process classes. Correct me if I am wrong. Couple of years back, I was guilty of same crime until I came across design patterns and I have never look back since then. Either I design good Object Model or bad but it is never procedural. 100% of prople who employ Domain Driven Design, get some controller and/or process classes right in first iteration or phase.<BR/><BR/><B><BR/>Class Diagram in conjunction with Activity Diagrams and/or Sequence Diagrams communicates more clearly than Database Diagram<BR/></B><BR/><BR/>Imagine a user showing following Table<BR/><I><BR/>Customer<BR/>Id<BR/>Frst_Name<BR/>Lst_Name<BR/>Addr_Ln_1<BR/>Addr_Ln-2<BR/>Cty_cd<BR/>State_cd<BR/>Zp_cd<BR/></I><BR/>Imagine a User being shown following class<BR/><I><BR/>Customer<BR/>Id<BR/>FirstName<BR/>LastName<BR/>AddressLine1<BR/>AddressLIne2<BR/>City<BR/>State<BR/>Zip<BR/>GetCustomerCreditHistory.<BR/></I><BR/><BR/>Which would make more sense to Business Users<BR/><BR/>By doing the above, you can successfully avoid the prototype data modeling. and say “See Mom no prototype ERWin Diagram” . Real ERWin Diagram may be prepared by DBA. Or you may just to map entity classes to Database Diagram.<BR/><BR/>You may say that when you are design entity classes , you are designing actually database table.<BR/><BR/>to be contiued...<BR/><BR/><BR/><I><BR/>Note: I may revise this post after completing the book for good or bad<BR/></I>Vikashttps://www.blogger.com/profile/11330187546301885403noreply@blogger.com