|
Just making sure you had the resource handy. If it were me, and I really wanted to know, I'd go look rather than rely on what some random dude(tte) on the internets had to say about it 
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
I already have the code. Not sure if you've ever seen it, but it's not trivial
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
If you only have a "few" entities, then one repository per entity is overkill IMO.
I wrap the whole DB context in a "repository" and tailor it to the "problem"; accessing specific entities "by name", like GetCustomer(id); instead of resorting to "patterns and generics" that make the whole thing more obtuse.
"SaveChanges" saves the whole "context"; that's why a "centralized" save makes no sense. For "big" object graphs and "batch jobs", one wants to save at appropriate intervals to avoid one (big) update stream.
"Hanging" onto db contexts for a "long time" is also a problem (and bad habit) for most.
Creating new db contexts is "light-weight", and helps avoid memory leaks. The "data base calls" are what impacts performance.
The actual number of "unique" calls that one makes to an ORM is rather small and "self-documenting" code beats generics when you start solving "application problems" and having to apply "user terminology" change requests.
Generics are fine for "tools"; not business logic; and "use case" ORM queries, etc. fall under "business logic".
(EF gets bad-mouthed a lot because of all the "patterns" others want to apply and the (bad) results you wind up having to contend with; not due to some inherent defect in EF).
Writing "fewer" lines of code is not necessarily progress; or without future "debt".
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
modified 29-Jun-18 16:45pm.
|
|
|
|
|
We have an Oracle data wharehouse that I want to set up a web API service to allow authorised applications to query, note users will not have access to the API only applications.
I would ideally like to have an environment where a developer can build and test a query, construct that as a DLL that conforms to a defined structure and drop the file into a folder which the API can find it.
Setting up an interface to service all queries should be fairly simple, query string and a dictionary or tuple of parameters. Then have the API deliver a JSon result.
I want to know if MEF will meet these requirements.
Assuming MEF will do this and the web API only accepts authorised, via token, requests are there any security flaws in the design.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Yes, MEF will work very well for this purpose. I've built similar systems before, and key sticking points for me were:
- Use a good standards-based query approach (like REST) so that you can build a concise base class for the DirectoryCatalog to pick up via [InheritedExport]. Trying to get fancy with specific method location (such as Dictionary<string,func<iowinrequest,object>> ControllerActions) will lead quickly to abstraction bloat and maintenance nightmares.
- Make sure you have your authorization model de-coupled from the controller (though metadata attributes can be used to provide this in concrete implementations). This may work with WebAPI2 out of the box, but I'm not 100% positive on that count (I used a custom OWIN web server for my implementation).
- If you're using an ORM, either make sure to resolve objects before they leave your controller, or make your data context a part of a request object that is passed to your controller actions.
Those are the biggies that have cause me tears over the years.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
My requirements are very simple and as I live behind the firewall security is a simple token implementation and yes it is separated from the controller.
I figure to have the DLL validate the input parameters and return a query string and a collection of parameters. No passing of actions/functions or generics.
No ORM, data context or models, just a Json string.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
So I have a IPTV app, at the moment its monolithic code and I want to spearate it out to make it more python-ic.
So,
I conceptually, I have:-
LiveTV which can play live TV Channels, or Video On Demand (VoD),
Both VoD and Live TV channels are a Stream,
A Stream has a name and a URL source.
A TVchannel is a Stream + a uid, a descriptive name, an EPG id, a channel-group, a logo-URL.
A VoD is a Stream + a playlength
An EPG which is a collection of Grouped TVchannels.
Then,,
I have an M3U file which defines sources of Channels and VoD, I have parsed and all works fine. But, from this I need to create a collection of TVchannels and a colleciton of Groups. For Groups, each Group contains a list of the stream uid so that the player can switch Groups and list all the streams (TVchannels / VoD) in that group - No need to store all channel info in each group, just the uid, which I can then use as a lookup into the colleciton of Channels.
The player can present a list of Groups and inside each list, the list of TVchannel names , to be selected for play. Or, the player can present an EPG and the user can select Groups in the EPG which will then list the channels and programmes.
All this works fine, but as I say, its monolithic and not OOP/Pythonic.
All I am seeking is advice/guidance/expertise on how best I could model the different elements of the app to maximise efficiency and modularity using types/classes the "Pythonic" way. In other words, a Pythonic architecture - how would you attack this? How might the architecture look if you were doing this. That's what Im interested in, views/opions/examples/rationale.
So, What I have tried:
Looked at modules, class, inheretance, properties, abstract classes, factories, lists, tuples, named tuples, sets, .... the list goes on. Ive got a headache, there are so many ways one might do this , but what would YOU do!?
I have read online Py Documentation, and read tutorials at TutorialPoint.
Also examined GitHub projects for simiar apps. Cannot find anything similar, but if i did, i would prefer an explanation which Im not going to get.
So this quesiton is not about training in OO/OOP, I dont need that, it is about the Python-ic way to implement such an architecture: @Property, setter/getters, discrete def()s, class attributes, instance attributes, lists/tuples/dicts, and how the class hierarchy might look if you were to attack this.
|
|
|
|
|
As I told you this morning in your question in QA, this is exactly about OOP. Python implements OOP just the same as all the other languages, with classes, inheritance and polymorphism. So any tutorial on the subject will apply equally. If you want the specifics about writing Python classes (which we also touched on in a previous question) then take a look at 9. Classes — Python 3.4.8 documentation[^].
|
|
|
|
|
Sigh, sometimes, i lose the will to live.
Richard, thank you for your reply, but really - it's best you save time and effort and not reply to my posts, honestly, unless you can help. In this case my impression is that you havent read the question and with respect have failed to grasp the nettle. I went to great lengths to articulate the scenario and you fail each time to understand - I'm interested in what others would do - I do not need training - I merely ask for other VIEWS Richard. look, Please save yourself frustration and reply to other posts on these forums more deserving of your time as this tends to be trend of yours.
We have a saying here
RTFM ... or rather in this case, RTFQ ! 
|
|
|
|
|
You asked what is the "pythonic" way to do this, and I answered that part: there is nothing in Python that is different from other object oriented languages. The documentation on Python classes is quite clear.
If you are expecting someone to do a complete design for you then I think you may be disappointed.
|
|
|
|
|
you just DONT GET IT Richard
please, please please please, assist elsewhere, you're so wide of the mark.
|
|
|
|
|
I'm already disappointed with feedback !!!!!
|
|
|
|
|
Yeah, life ain't always fair.
|
|
|
|
|
Your "design" is a long way from worrying about language-specific implementation details.
You've identified a few high-level components; too high level for anything. No kernel.
And as others have pointed out repeatedly, "object oriented design" is NOT language dependent; you have a lot more work to do first.
Logical design precedes physical design (your "python").
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
as "others have commented" WTF , there's only one guy who can't answer, well, now two!!
I've dune 6 had a thoroughly interesting debate on another forum full of inspring ideas and, people.
this place is a joke
|
|
|
|
|
ninjaef wrote: this place is a joke
Well only because of the questions that get posted. 
|
|
|
|
|
nope, by the incompetent replies that , well , have zero value. Complete waste of time replying. Why bother. Annoy someone else instead.
|
|
|
|
|
Oh no, it's much more fun annoying people who think that they own these forums, and we are their slaves.
|
|
|
|
|
Yes, indeed i have had great fun in doing so.
|
|
|
|
|
So two people have completely "failed to grasp the nettle", and you assume the problem MUST be that they're idiots, or that this site is "a joke".
The failure to communicate couldn't possibly be a problem with your question, could it? 
Back away from the computer. Take several deep breaths. Go and do something relaxing for a while. Then come back without the attitude, and explain your question in more detail. If someone doesn't seem to understand, then don't fly off the handle; explain it in yet more detail. Keep elaborating until either they understand, or the solution jumps out at you.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
If I said: "as other pointed out", it would also sound funny and you would probably make hay of that too.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
The problem here is that Pythonic refers to a using the language in such a way that it is clear, maintanable and concise. That's not really an aspect of how you break down the design of your architecture; rather it's a case of, when you have your architectural domain designed, how do you use the language following Pythonic principles and, more importantly, how do you structure your code so that others can use yours in a Pythonic way. I really do think you are conflating two separate problems in this question.
This space for rent
|
|
|
|
|
I want to allow the user to create their own lookup values that would be populated in a combo box. For example, an account's Statuses might be New, In Progress, or Closed. The use can Add, Edit, and Remove these from the lookup table at any time.
For this, I have a lookup table with Id, Caption, and Category. Other tables might have a StatusId that has an FK to Lookups.Id.
So, some questions:
1) Before they can remove a status I would like, to ensure that the Id isn't in use. I could query each table that it the target of the FK. Is there a simpler, more manageable way?
2) I would like to take action when the user selected the Closed option. How do I know for sure that this particular Lookup item was selected? Since it can be renamed I can't rely on the caption. I could have some other column in the table with some identifier in it and check that identifier in code, but that couples the code to a specific data item.
Thanks
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Oh you are in for a world of hurt going down this particular rabbit hole.
Most/some lookup tables have a consequence in your code - how do you associate a new status with an action.
A generic lookup table simplifies the maintenance until you find a lookup that does not fit your structure (this always happens 2/3 through the project). I now have a table for each lookup type, I decide which ones can be edited. The delete procedure has to deal with FK and usage issues.
I recently got called a dinosaur by an out source architect for insisting on this structure, they then went down the generic path. I got a laugh when they ended up with a 3 table generic structure that was so complex the developers got lost trying to maintain it. F***ing whipper snappers.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Don't "delete", use "expiry dates" for your lookup entries; don't show "expired" ones in the maintenance views except in "browse" mode.
Insures referential integrity ... even "years" later.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
