This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
Relational UML Diagram inspired by SO
I have developed my homework from the post.
Problem: to do posts similarly as in SO so that the first post is the question and the other posts are replies after the question.
Question: How would you improve the interfaces? Would some simpler data structure make things easier?
Your first question confuses me. UML makes me think of objects and "Posts-table" makes me think of relational databases. Which one do you mean? I'll assume that you want objects.
You need an interface or abstraction that represents both questions and answers - maybe that's the Post interface. It'll have attributes like text and author and a timestamp when it was posted.
Since the question will never come before an answer, if you have a collection of Post instances it'll be in the proper order if you sort it by timestamp.
UPDATE: UML means object-oriented programming. Python is both an object-oriented and a functional language. So that means you'll be thinking about the problem in terms of objects first.
Thinking in terms of objects means setting aside concerns about user interface and database. You design the objects to provide the kind of behavior that you need. You can have a simple text interface at first, and object serialization will do for persistence. But get the objects right first.
When you say "interface", I think of Java interfaces. They declare the signature of the class, but say nothing about implementation. So your Post interface might have Question and Answer implementations.
What contains all the Post instances? What owns them? I'd have another object called KnowledgeExchange to own the collection of Posts. Let it hide all the implementation details and provide methods to getQuestion and getAnswers. Don't force your clients to have to know all those details or even whether or not you implement it as a stack or list.
Like I said, don't worry about tables or persistence just yet. Think about objects. Best to make the whole problem in terms of objects instead of just Post, Question, and Answer.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I am looking for a full web (MVC or WebForm sample application which is based on CSLA 4.0. Any ideas? I think its ProjectTracker sample is WinForm only and based on older vesion of CSLA.
Mark's experience with CSLA seems to be quite outdated. Nearly every point he made is inaccurate. CSLA is for user's use-case scenarios. Especially data-binding to UI's.
1) Using the folder analogy is completely inappropriate. You can have a single business object act as both a parent and child if you so choose, just not the same instance of your business object. Lazy loading of children is completely supported as well.
2) The serialization overhead is no more than what RIA services does, as CSLA uses the DataContractSerializer to utlimately serialize objects. Additionally MobileFormatter has been updated to allow for custom serializers. Now binary is supported as well as the original xml. Ultimately it all still goes through the DataConstractSerializer.
3) You can create any kind of DataPortal replacement, including using JSON within your own custom DataPortal. And CSLA command objects support managed properties, so serialization works exactly the same way as business objects.
4) It's true there is no in-place merge, however, I've never found this to be a problem.
5) Subscribers never get serialized with the business object. If your DataPortal is only local, then the original object is sent(not serialized) and so any subscribers it has will naturally still be attached.
I have no problem leveraging CSLA in both Windows Form and Silverlight environments. For 95% of the business user use-cases CSLA brings a lot to the table.
http://www.lhotka.net/cslacvs/viewvc.cgi/core/trunk/Samples/NET/cs/ProjectTracker/Mvc3UI/ is the MVC3 Part of the famous CSLA ProjectTracker sample. This might be the
one to learn from.
Rocky himself checked a change in just 2 days ago, so this is probably as Cutting edge
as you can get for an CSLA sample, from the author himself.
Here are instructions on pulling code from svn
http://www.lhotka.net/cslanet/Repository.aspx
My advice - do not use CSLA. I am going to quote my reply to https://stackoverflow.com/questions/1234/have-you-attended-the-csla-master-class:
I have a two years experience with CSLA. In fact, when I started our
project I really did not want to write an entity framework from
scratch, something that was done in all of my previous jobs.
So, I picked CSLA. As any entity framework, it has good and bad
points. I will list a few of the bad ones, because the good ones are
described in abundance on the CSLA related sites. So, the nays:
CSLA parent-child relationship does not support folder-file pattern, where files are children of the parent folder, but they are
also independent entities. In CSLA, children are integral part of the
parent, so you cannot, for instance, update/delete/add a single child
without updating the whole object tree. Forget about lazy loading of
children - no such thing. In short, if your data model represents a
folder-file like structure - do not use CSLA. We had to twist CSLA
arms to let it support this mode.
Huge overhead in terms of state. Define a business object with 3 properties. Now send it over wire using some http binding. Pay
attention to what gets transmitted. I know XML is not the best
serialization vehicle, but your 3 properties are translated to ~4KB of
XML. What does it include? Business rules and field data manager state
among others. Extremely bloated. We employ zip compression, but still
this is very disturbing.
Silverlight does not have normal serialization engine, so CSLA comes with a Mobile serialization, which is good if there is nothing
else. The thing is that there are other things - JSON and protocol
buffers, but CSLA is incompatible with these techniques. And Mobile
serialization, although it solves the problem, it is a real pain when
it comes to commands, because there you have to implement it manually
(unlike business objects, which support it automatically for each
managed property). Remember CArchive from MFC of 10 years ago? This is
it.
Saving an object does not merge the new state in-place, rather returns a new object. We had much problems in Silverlight with the
fact that every save replaces the object tree. So, we had to override
the CSLA default behavior and implement in-place save with all the
associated complexity of merging new state with the old one.
You quickly loose control over what is actually transmitted on the wire. For example, here is something I have discovered while examining
the CSLA source code. Serializing a business object also serializes
all the serializable subscribers to its PropertyChanged and
PropertyChanging events. So, when such an object is sent to the
server, it carries along with it all the serializable subscribers to
these events. From the mobile object philosophy this is fine - mobile
object simply preserves its living environment across the application
tiers. From the practical point of view I find this a disaster waiting
to happen. Needless to say that I have disabled this feature right on
the spot.
Looking back after 2 years working with CSLA I have came to a conclusion that many others already came to before - your server side
objects just not the same as your client side. Trying to pretend they
are yields a lot of grief later in the development. And this is
probably the most important nay to CSLA. The concept of mobile objects
seems right at first, but as the project grows and the server and
client sides develop having the same object type on the server and
client becomes more of a liability rather than advantage - the
internet is full of discussions on the matter.
Bottom line - I would not have used CSLA if I had the same
understanding as I do now back then when I have started the project.
CSLA gives you much stuff out of the box and I like DataPortal concept
very much, but I see that I could have done fine without them and be
in a better place now.
These are my 2 cents.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Im starting working with Moose/Perl and im searching for an UML Tool to create diagrams and representing the Moose OO System. I already worked with Astah (former Jude) but it is designed for Java OO System. Can someone give recomend other UML tool to work with Moose/Perl?
My two cents:
I have written an extension (a .xom file) for Sybase PowerDesigner. This tool has a powerful metaclass editor that you can script with vbscript and a proprietary language, GTL. It also has large collections of customizable metaclasses and templates.
My PowerDesigner Extension is quite hacky and contains some stale code that I didnt clean up. Therefore I haven't published anything. It works for me, and only for me. Some lessons learned, from the top of my head:
I wanted to do UML modeling and code-generation, do you want to do that, too?
Moose is quite attribute-heavy so a UML approach is worth doing in this respect.
Didn't use roles much, but I tried to map them to interfaces anyway.
I am not satisfied with how to model relationships. Lots of edge-cases and "impedance mismatches" of UML concepts and moose/perl concepts. (BTW, Whats the moose equivalent of an "association class"? )
Native traits are a nice feature in Moose but I haven't succeeded in creating a GUI for editing them
I also hurt my brain by designing a comprehensible GUI for type coercions (I often need to check + coerce date values)
Static attributes are an important feature in UML but less important in moose. The problem is that there is no "static" keyword in perl/moose, but you have to declare a "use MooseX::ClassAttribute" or whatever it is called, and do it only once per class, but in the right place (order matters)
the code generated is impossible to pretty-print, so usually I send it through perltidy right away, to bring it to a "canonical" form, making diffing and versioning / committing to SVN easier.
When a class is generated , the compactness of Moose class is gone, you'll have svn properties, header comments, lots of "use" + "use lib" statements, lots of POD, some comment lines after each sub declaration with parameter-passing doc, the the obligatory footer ("no moose ....")-
unfortunately, reverse engineering Perl code (to update a UML model from code) is impossible. Thus, at some point I must stop working in the UML tool, and start to edit the perl code directly, abandonig the model. Checking back in these changes must be done manually at some later time, is very time consuming and requires care.
Advantages:
Generating properly POD-documented code is the main productivity gain you'd get by doing all this UML modeling, IMHO. Good for "enterprisey" programming environments.
you can autogenerate *.t files with testcases (or stubs of testcases). Requires some thinking to design smart tests, and to avoid the problems Dave Rolsky has written about in this blog post: "add(ing) absolutely nothing that isn't already tested by Moose itself"
You can define custom checks in the model such as "check if builder methods for all declared attributes exist, and if they don't exist, create a stub, or (ask me what to do)"
easy mapping of nightmarish database tables to moose classes. (I have to work with lots of multi-column tables that cannot be touched). Build your own graphical ORM-Mapper!
there might be even more advantages
I haven't seen a UML tool yet for Moose. It wouldn't be that difficult to build one, just a little labor intensive. Mostly it would require crawling the meta-class tree for a given class and outputting the proper UML markup for each step. If are interested in building something like this, you can stop by #moose on irc.perl.org. Someone I'm sure can help point you in the right direction.
Just stumbled across your question while looking for "UML Moose perl".
One of the other links thrown up was to a utility called umlclass.pl that looks quite interesting.
I'll post a follow-up after seeing how well it works.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Just wondering how to start a project from concept,specs,dev etc. In development do you start with database design? or maybe theres a resource you know i can look at.
Starting with database design is actually a big pet peeve of mine. Sure, it's fine for some projects. Simple forms-over-data apps, stuff like that. But for anything more complex, anything that has a "domain" of logic, do not start with database design. Start with domain modeling. If you're taking business logic and putting it in code, then it's highly likely that the business users who define the logic flow do not think in terms of SQL or relational data at rest. They think in terms of logical interactions of concrete and abstract concepts.
As Eric S. Raymond said, "Smart data structures and dumb code works better than the other way around." Usually, when one starts with the database design, one creates a flat "dumb" data structure. Not dumb in the sense that it's a bad design, but in the sense that it has no built-in logic. It's flat and dimensionless. All of the intelligence would need to go into the code that uses it.
A rich domain model, on the other hand, incorporates business logic and concepts directly into the data structures. It's enhances the data itself with actual business intelligence, carrying that intelligence throughout the domain.
Now, this doesn't mean that you shouldn't think of persistence at all while designing the domain. But the persistence should be built to accompany the domain, not the other way around. Nilsson suggests starting with the domain and during the development of it take breaks to think and work on the persistence. This is because the domain model is really the core, but you'll need to evaluate any compromises on persistence to keep yourself realistic. Going for true persistence ignorance could dig yourself into some holes.
That all depends on what sparked the motivation to start a project in the first place. It could vary from sitting down and fleshing out detains of something that's been brewing amorphously in your mind for years, or sitting down and making a quick and dirty prototype to convince yourself that the genius idea you had that seemed so simple is actually quite a thorny bush that requires you to sit down and flesh out.
I never start with database design, as that's an implementation detail. I might not even want to use a database. I start with the functional design. What do I want it to do? Why? How? How does it do it differently from other approaches? Is the benefit enough to even bother doing it at all? You get the idea. Implementation design is tackled once I know clearly what I am doing and most importantly why.
That is very general but the first step is always to figure out and document what you want the application to do. Then I usually develop and ERD which defines the tables required to accomplish those functions along with the class structure that sits in front of those tables. Once those two big parts get done, it's usually pretty smooth sailing.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are the best practices for NoSQL Databases, OODBs or whatever other acronyms may exist for them?
For example, I've often seen a field "type" being used for deciding how the DB document (in couchDB/mongoDB terms) should be interpreted by the client, the application.
Where applicable, use PHP as a reference language. Read: I'm also interested in how such data can be best handled on the client side, not only strictly the DB structure. This means practically that I'm also looking for patterns like "ORM"s for SQL DBs (active record, data mapper, etc).
Don't hesitate making statements about how such a DB and the new features of PHP 5.3 could best work together.
I think that currently, the whole idea of NoSQL data stores and the concept of document databases is so new and different from the established ideas which drive relational storage that there are currently very few (if any) best practices.
We know at this point that the rules for storing your data within say CouchDB (or any other document database) are rather different to those for a relational one. For example, it is pretty much a fact that normalisation and aiming for 3NF is not something one should strive for. One of the common examples would be that of a simple blog.
In a relational store, you'd have a table each for "Posts", "Comments" and "Authors". Each Author would have many Posts, and each Post would have many Comments. This is a model which works well enough, and maps fine over any relational DB. However, storing the same data within a docDB would most likely be rather different. You'd probably have something like a collection of Post documents, each of which would have its own Author and collection of Comments embedded right in. Of course that's probably not the only way you could do it, and it is somewhat a compromise (now querying for a single post is fast - you only do one operation and get everything back), but you have no way of maintaining the relationship between authors and posts (since it all becomes part of the post document).
I too have seen examples making use of a "type" attribute (in a CouchDB example). Sure, that sounds like a viable approach. Is it the best one? I haven't got a clue. Certainly in MongoDB you'd use seperate collections within a database, making the type attribute total nonsense. In CouchDB though... perhaps that is best. The other alternatives? Separate databases for each type of document? This seems a bit loopy, so I'd lean towards the "type" solution myself. But that's just me. Perhaps there's something better.
I realise I've rambled on quite a bit here and said very little, most likely nothing you didn't already know. My point is this though - I think its up to us to experiment with the tools we've got and the data we're working with and over time the good ideas will be spread and become the best-practices. I just think you're asking a little too early in the game.
"NoSQL" should be more about building the datastore to follow your application requirements, not about building the app to follow a certain structure -- that's more like a traditional SQL approach.
Don't abandon a relational database "just because"; only do it if your app really needs to.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I am just starting to play with Django/Python and am trying to shift into the MTV mode of programming that Django asks for (insists on). Deciding on what functions should be methods of a model vs simple being a function in a view has so far been confusing. Does anyone know of a book, website, blog, slideshow, whatever that discusses Web Framework programming in more general, abstract terms? I imagine just a book on object oriented programming would do it, but I feel like that would be overkill - I was looking for something web framework specific.
My basic rule in Django is: if you could conceivably need the functionality from somewhere other than the view itself, it doesn't belong in the view function.
I'd also recommend downloading some of the plethora of apps on Django Pluggables and seeing how they do it.
Once you do find some good guide, here's something to remember: Django is a bit special with its terminology. It uses "MTV" for Model, Template and View (and can mention also a URL Dispatcher somewhere along the way), whereas a more standard set of terms is "MVC" for Model, View and Controller.
Model is the same in both meanings - a model of a data entity, often linked to a database table, if the framework implements Object/Relational Mapping (which Django does).
But the two remaining terms might be confusing; where Django talks about Views, the 'rest of the world' talks about Controllers. The basic idea is that this is where the presentation logic is done. Calculations are calculated, arrays are sorted, data is retrieved, etc. I'd say that Django's URL dispatcher is also a part of the conventional Controller concept.
Django's Templates are comparable to Views elsewhere - here you have your presentation, nothing else. Where Django forces you to a very small set of logical commands, other frameworks often just recommend you not to do anything than present HTML, with some presentation logical elements (like loops, branches, etc), but don't stop you from doing other stuff.
So, to recap:
Model: Data objects
Controller (View in Django): Data process
View (Template in Django): Presentation
Oh, btw: For a Django-specific guide, consider reading The Django Book
I've not really used Django in anger before, but in Rails and CakePHP (and by extension, any MVC web-framework) the Fat Model, Skinny Controller approach to organising your methods has been a real eye-opener for me.
If you aren't absolutely set on diving into Django and don't mind trying something else as a start, you might want to give WSGI a shot, which allows you to template your application your own way using a third party engine, rather than having to go exactly by Django's rules. This also allows you to peek at a lower level of handling requests, so you get a bit better understanding of what Django is doing under the hood.
Here are a few links that might be helpful as an overview.
From my own experience, when I first started using MVC based web-frameworks the biggest issue I had was with the Models. Prying SQL out of my fingers and making me use Objects just felt strange. Once I started thinking of my data as Objects instead of SELECT statements it started getting easier.
MVC In laymen's terms
MVC: The Most Vexing Conundrum
How to use Model-View-Controller
View function should only contain display helpers or display logic. View functions should never access the model itself, but should take parameters of model data. It is important to separate the model from the view. So if the function handles accessing the database or database objects, it belongs in the model. If the function handles formatting display, it belongs in the view.