Tag Info

Hot answers tagged

14

Waterfall model is a software development process consisting of a sequence of phases (requirements, design, construction, testing, deployment, maintenance), followed from first to last one, without going back and without using iterations (unlike in Agile models). Waterfall model helps modeling project management. Object-oriented model is a representation ...


8

The key is: Separation of concerns In an ideal world you want any given piece of code to do one thing and to do that well. So you want to try and avoid mixing up display logic and business logic and storage logic and everything else. This separation provides a variety of benefits - testability (as suggested) is an important one (though to my mind it's ...


7

I didn't like the fact that i was tied to a specific ORM implementation... Why not? Are you afraid you will pick the wrong one? That sounds like a case of "Not Invented Here." You are going to be dependent on the chosen language, and SQL, and the web framework, and a dozen other things. An ORM is just one more. As long as the performance through ...


7

You questions contains IMHO three misconceptions: "design" does not necessary mean "UML model". On the contrary, in the context of software development "design" most often just means "the overall structure of a program, program system, or program code". Parts of that structure can be visualized by UML diagrams, but don't interchange the visualiziation of a ...


7

V-model is an extension of Waterfall model, so don't expect it to be hugely different. Basically, you follow V-model from left to right, just like in Waterfall model. In Waterfall, you do requirements, design, implementation, verification and finally maintenance. In the same way, in V-model, you do requirements, design, implementation, verification and ...


6

I know you're trying to simplify your scenario to make it easier to discuss, but why does the OrderItem care about the Header? The Header is Aggregator (called the "Root" in DDD) and it is responsible for knowing about its components (OrderItem being one of them). If you're discussing special cases like Discounts being applied to Orders containing for ...


6

While it is true, that the standard enterprise architecture is pretty close to the three-layer model, truth to be said, it actually means harder maintenance. If you grab an SVN/CVS/git/... log of an enterprise application with considerable history, you'll find out, that the rate of change is as follows: views change all the time models change about as ...


6

Wrong is a big word. The reason why you shouldn't put it in the DB, is because the vocabulary of (most) DB systems is incredibly limited. There is nothing about "SELECT", "INSERT", "UPDATE", "DELETE" that allows you to fluently express why something is happening and to what it is a reaction, in domain language terms. As to the second part of your question: ...


5

This is a fairly common situation and your choice of pattern is very dependant on the circumstance and your personal preference. Where you're not simply writing a CRUD application, you can have a domain model which models the business domain and a view model, specific to the application, for displaying and editing that data. Some would argue that even when ...


5

Do the classes really need to be decoupled? In your example, from business point of view, the order header and order item are entities, that are really close. They probably form an aggregate. So trying to decouple those will create unnecessary complexity and will make reading the model confusing. To solve this, I would try to locate aggregates in your code ...


5

In your OP you asked for an instance when using an ORM is "bad". I wouldn't go so far as to say ORM is bad, but it has consequences, not all of which are good. ORM's generally follow the Active Record pattern* (because Data Mapper is a bit tricky) this tends to impose design decisions on the database that favour application code Here's a great quote from ...


5

First, it is almost every time a mistake to argue about the place of the business logic in terms of program speed (at least, when your model and controller layers are part of the same program with no network communication between them). If you have speed issues, you can optimize them in your model layer as well as in your controller layer. Much more ...


5

These are completely different beasts. The waterfall model is one of the ways to organize software development process dividing it into sequential stages known as Requirements, Design, Implementation, Verification, Maintenance. For example, your boss told you you have to develop an online shop. According to the waterfall model you first have to analyze the ...


5

Model: Fields that belong to the object, methods that help to get/set data from the object (a fullname accessor that returns first + last name) Service: Methods to perform operations with one or more models, see 'unit of work', transactions, etc... Employee::create should just take a set of data, perform model validation if necessary, and return an ...


5

The reason that you can't find a one-to-one mapping between the views of the 4+1 Architectural Model and the various UML diagrams is because such a mapping doesn't exist. What all those authors are trying to tell with their 'mappings' is that for each view, there is a different set of UML diagrams that can be useful to convey the information that you want ...


4

I do think you kind of answered you own question - Models should simply include basic data-related logic, and every other more abstract functionality should be handled by library classes (IMO - should be taken with a grain of salt, as there are a lot of definitions of MVC and the likes for the web). So, to extend on your example: the User class, would have ...


4

The problem with Django models (or rails active record its the same pattern) its that this is not a behavior model of your application, its a data model, with this architectures your application are tightly coupled to the database. Problems of this types of applications: The design of the database dominates the design of your application. Normally you end ...


4

Although I generally agree with Bart van Ingen Schenau's answer, I think a few points need additional elaboration. Th advantage of the 4+1 View Model is that it maps stakeholders to the type of information that they need, without requiring specific modeling notations to be used. The emphasis is on ensuring that all groups have the information to understand ...


4

The array can also called a ViewModel, it is different from the Model because it carries the data the view needs while the Model represent the application business entities. For simple CRUD form they are likely to be identical. But for complex form, a ViewModel can be combined from many models.


4

If Solver is appropriate depends primarily on how you build your model for the given problem, and if the problem size stays within the boundaries of the solver. According to this site, the limit for Excel Solver is 200 decision variables and 100 constraints (they are also promoting their premium solver product for bigger problem sizes). But when you use ...


4

Just some thoughts. (Mandatory disclaimer: use of the information for purposes other than strictly personal use or entertainment, or use for purposes that may harm safety or cause loss of assets or life, is strictly forbidden.) Since I'm not certain about what you mean by "entity", I will just list the properties (model and behavior) a person (who can ...


3

The pattern I have settled on for creating my view models is SomeViewModel is created by a static method (or instance method if appropriate) on SomeViewModelFactory. I don't inherit from base models for members that are duplicated. I use interfaces and external setter methods that operate on those interfaces to set the properties. This abstracts away the ...


3

I would probably minimize the amount of "locking myself away" if I were you as you'll want feedback sooner rather than later. A major point of DDD is developing a ubiquitous vocabulary (UV) so that the developers and the users are speaking the same language and describing thing the same way. You cannot possibly do this on your own--you have to talk to the ...


3

A pluggable model, using MVC (at a larger system level than what Swing defines MVC as), or a facade pattern would all work


3

What I am going to say probably sounds very generic, and to a degree it is, but it can be applied to any engineering problem. Software is generally used to deal with problems in the real world. In consequence it models those parts of the real world it deals with. The more accurate the model is, the better you can deal with the real problem, but at the same ...


3

Permissible?...yes I would break-up a User class into parts in cases where it might need to scale really big. Model Breakdown Example (Composition): User HAS LoginCredentials ContactInfo Favorites Friends Roles


3

Ask yourself whether the class has more than one reason to change. Acording to Bob Martin's explanation of Single Responsability Principle: As an example, consider a module that compiles and prints a report. Such a module can be changed for two reasons. First, the content of the report can change. Second, the format of the report can change. These ...


3

I'll leave whats 'bad practice' to the bloggers to fight over. I personally keep queries within the business-logic objects. So yes, User, Order, Sale, etc. I'd find it very inconvenient if they they were all in a separate file. That would be unnecessary added complexity and frankly kind of annoying to have to keep referring back to the file. If for ...


2

I do a lot of work with Geographic Information Systems (GIS). Part of working in this domain requires handling and storing all sorts of spatial data, which we usually leave up to software vendors like ESRI or use open source solutions like GDAL. GDAL can also be plugged into C++ and python programs easily. There are also several spatial databases out ...


2

Testability. Decoupling user interface from the model makes it easier to write tests against just the model. You just test against the core functionality, without having to worry about User Interface getting in the way (which you may test as well, and there are ways to do that, but this is not what you are asking :).



Only top voted, non community-wiki answers of a minimum length are eligible