Hot answers tagged model
7
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 ...
6
Finding a suitable model isn't always straight forward. It is one of these things which require more experience than plain knowledge. However, the following simple recipe might help you to get over an initial mental block.
It was originially described in this paper by Abbott and is frequently referred to as "Abbott's textual analysis".
Write a plain text ...
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 ...
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
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 ...
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 ...
3
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 ...
3
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 ...
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
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 ...
3
In my opinion, taking TDD approach is natural and efficient:
Write down specific requirements (Given, When, Then)
Translate each requirement (most important one first) into a unit test.
Write least amount of code in order to pass the test written in #2.
After passing the test, refactor your code according to SOLIDD design principles.
After #4, make sure ...
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
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 ...
2
The fact that your book says you should always code in that model is a red flag that it is not a good book.
Different situations call for different paradigms and design patterns. If you feel that that pattern would fit, go ahead and use it. Otherwise, go with what you're comfortable with.
However, don't get caught in the trap of thinking well it won't be ...
2
I am generally acutely aware of the value in completely separating out
my actual Models from the Data Access layer, so that the Models are
completely naive when it comes to Data Access.
This is referred to as persistence ignorance. Another concept you may wish to introduce in your data access layer is the repository. The central function of a ...
1
It sounds like you are planning on making Model and all these object classes mutually dependent. I think this is a bad idea that will make testing and maintenance very difficult. Probably none of the object classes should depend on Model. If the Model needs to react to object state changes, then you could have the Model observe the objects.
1
One way to do it is, as you said, to create interfaces between the classes. Each class would take its dependencies as interface references that can be mocked or stubbed in a unit test context. This might make you think a bit more about the essential parts of the design that are needed by each class. For example, you might find that the order item does not ...
1
Would you have other ideas on how to break this coupling in the model classes? Or, how to make it easier to unit-test the model classes?
In my opinion, coding against the interfaces is the way to go. In another words, de-coupling your code by design is the approach that modern projects do follow. That greatly helps with the needs of unit-testing.
In ...
1
I agree with pdr that this is a common situation – in fact I’ve been dealing with it throughout my 20 years in software engineering. Consider the simple case of a managed database and its users. Users write queries to return result sets. Result sets are tables – so each user can build their own model from the internal data model. At some point a user asks ...
1
It all depends, surely, of what are your options.
You should understand that alternative to "(anemic) domain model" is not "something without strong-typing", but "data transfer objects". Both are strong-typed (with all included benefits), but there's strong semantic difference between them.
1
The three-tier model is well-suited for business applications, of the transactional variety (i.e. multiple user accessing a database). For other types of applications, such as games, highly interactive user interfaces or other real-time data processing, I wouldn't necessarily reach for a multi-tier model, however. So it depends on the nature of the ...
1
I am not sure what do you mean by "Domain models already created". However, here is a shot.
Microsoft provides sample databases with both schema and data that you can download and install.
The sample databases are Northwind and AdventureWorks.
A different download is provided for each version of Microsoft SQL Server, so be careful.
1
Turn the problem into a group of smaller problems (Modules if you like) that each have a single responsibility. For example "Generate problem method" is too high level to think about implementing. (considering all the different types of problems you have talked about generating: Worksheets, Diagrams etc.) If you split it into smaller parts you can then focus ...
1
I'm thinking the models should be abstract and users of the library should extend them into concrete classes which relate to their specific classes.
If some relationship needs to have different cardinality, you can handle that using model inheritance- have a base class which does not define the relationship and which has template methods for the code ...
1
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 :).
1
The difference is going to be the number and granularity of HTTP requests that go over the network.
Method 1 is going to send fewer, larger requests that perform operations on a batch operations. Method 2 is going to send more, smaller requests every time an object's property is modified.
Method 1 is also going to give you the ability to queue up a bunch ...
1
Here's steps I use in c++ code:
decide class name
decide constructor parameters and data members.
decide member function names and prototypes
make it independent of other classes
The design is done, and everything else is just the implementation.
The reason for (1) is that it defines the scope of what functionality belongs to the class.
The reason for ...
1
MVC as we all know, is composed of Model, View, and All the rest.
Where does authentication fit? everywhere.
It's fundamentally a layer on top of MVC, but then it also needs to get back down into MVC to integrate itself with the View, and the Model.
Authentication is such an ongoing problem with the MVC model and with object orientation in general, they ...
1
Your "resources" should be abstracted into a repository class. Your controllers can access the "resources" through the repository. This gives you the ability to change the underlying "resources" model, without breaking the application. It also gives you a place to put in some security, as needed.
Only top voted, non community-wiki answers of a minimum length are eligible
